Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why git is so fast (or why Java is not as fast as C)

marc.info

Post reply on HN
Print view View original

41–50 of 110 posts

Re: Why git is so fast (or why Java is not as fast as C)

#41

Post by berntb »

Deestan wrote: post #29
axod wrote: post #20

Earlier quoted context omitted.

Agree. If your bottleneck is your source control tool, you're doing something wrong.

Anything that is part of the programming routine should be severely optimized. Every little bit not only adds up, it often multiplies in big enough projects. In one of our big products, we have several build steps that touch upon the source control systems. 10 second VCS delay X 6 build steps, 1 second lazily written c++-header slowdown X 300 files, etc. and before you know it something that should take 10-15 minutes…

Thank you for reminding me about compilation time.

Now I won't be tempted to go back from scripting language country for a few more years... :-)

Edit: I should add that I have very fond memories about my youth and C, too.

Re: Why git is so fast (or why Java is not as fast as C)

#42

Post by igouy »

rikthevik wrote: post #10
Locke1689 wrote: post #5

Earlier quoted context omitted.

Couldn't agree more. One thing to remember though: "Premature optimization is the root of all evil." C Git is optimized and fast. Mercurial, with a combination of Python and C, is almost as fast. Maybe not quite as fast, but fast enough for me. A lot of the time those optimizations just don't pay off in terms of programmer time.

...Maybe not quite as fast, but fast enough for me... Given how fast computers are these days, the powerful standard libraries high level languages give you and the fact that bugs per line is constant regardless of language - high level languages start to look pretty good. Programs don't need to be fast as possible, they just need to be fast enough.

> the fact that bugs per line is constant regardless of language

"fact"?

More like an observation that must be re-tested and re-established with each change in tooling.

Is Java bugs per line the same for IntelliJ IDEA and Emacs?

(And of course let's remember - bugs per line when? During development? In product?)

Re: Why git is so fast (or why Java is not as fast as C)

#43

Post by blasdel »

barrkel wrote: post #27
blasdel wrote: post #25

Earlier quoted context omitted.

I found that I had to read your comment carefully to realize that I agreed with you, because I'd already flipped the bozo bit 3 words in when you unnecessarily used parochial microsoft nomenclature.

What word would you recommend I use to cover everything from Ruby to Java? FWIW, I think you'll make the same mistake pretty often if you continue to think of folks who play in the MS pond as bozos. There are reasons MS is a leader in many markets.

Anything but 'managed' -- while conceptually it covers things quite nicely, in practice it's used almost exclusively to mean "runs on the CLR", by those living solely within the Microsoft ecosystem whose knowledge of programming languages comes from Microsoft marketing materials. It's a loaded term.

There's plenty of nomenclature abuse in that ecosystem, like using 'assemblies' to refer to packages or 'blittable' for SHM.

'Garbage Collected' (or GCed) works fine instead of 'managed', especially since 'runs on a VM' is pretty nebulous, and the whole C++/CLI thing adds some confusion.

Re: Why git is so fast (or why Java is not as fast as C)

#44

Post by igouy »

jbellis wrote: post #37
richardw wrote: post #19

Earlier quoted context omitted.

'Modern JVMs can make on the fly optimizations based on the runtime profile' That's something I've heard ever since hotspot came out, but it's not a silver bullet to beating C/C++ etc. Here are some server tests. Some are comparable, some are definitely not: http://shootout.alioth.debian.org/u64q/java.php

"Sometimes no-warmup is important (see comments above about pacemakers), but more often a short warmup period is irrelevant to the overall application. If I'm using an IDE, I expect a largish loading period... but then I'm using the IDE all day. I don't use an IDE for 0.1 sec. If warmup is NOT important to the application, then allow the JVM a warmup period before comparing performance numbers. Many of the benchmarks…

The replies I post never seem to appear on that blog so here they are:

http://www.reddit.com/r/programming/comments/9ic0x/java_vs_c...

And measurements:

http://shootout.alioth.debian.org/help.php#java

Re: Why git is so fast (or why Java is not as fast as C)

#45

Post by richardw »

bad_user wrote: post #34
richardw wrote: post #16

While I'd never claim Java is comparable to C, I'd like to note that the C codebase has, by their admission, 4 years of work in it. I'd be surprised if the JGit codebase isn't much faster in 3/4 years.

The Git codebase has been heavily-optimized from the start. Its speed when branching/merging was its main selling point, ever since Linus started talking about it. The only way JGit would ever be equal-to or faster than Git is by using better algorithms. And somehow, I don't see this happening ;)

Nobody's claiming equal-to or faster - currently JGit is twice as slow so there's a lot of room for improvement. Faster than now, not faster than C.

Re: Why git is so fast (or why Java is not as fast as C)

#46

Post by [deleted] »

jerf wrote: post #38
axod wrote: post #15

>> "why Java is not as fast as C" Not actually true in reality. Modern JVMs can make on the fly optimizations based on the runtime profile, which would need to be done by hand in C. As said elsewhere though, Java excels when used for long running tasks - servers - backends etc where it can optimize for the long term. It doesn't excel when you try and start up the jvm loads of times for quick individual jobs. I don't…

You're bringing theory to a shootout based on facts. Hypothesizing that Java might be faster with a strong enough headwind doesn't make the actual, factual JGit run faster or C-git run slower. I mention this because programmers seem prone to this, and letting theory trump fact is a great way to make sure that you never learn anything.

[deleted]

Re: Why git is so fast (or why Java is not as fast as C)

#47

Post by DougBTX »

axod wrote: post #30
JulianMorrison wrote: post #26

Earlier quoted context omitted.

Speed changes your workflow. With slow or fussy source control, you're more likely to do "branches" by just not checking in your changes for awhile. With near-instant source control, you don't feel burdened by making a feature branch, switching, editing and committing a few times, and merging back.

True, I don't really like using branching/merging as a workflow unless absolutely necessary. So sure, if you're constantly branching and merging all day, then I can see it being a problem. But I'm not convinced branching+merging is really good for your productivity. The other point is that with a distributed system like git, all of the load is on your local machine. With a centralized system like subversion, the serv…

But I'm not convinced branching+merging is really good for your productivity.

Because branching and merging are slow? I can see this argument getting stuck in something of a rut.

Re: Why git is so fast (or why Java is not as fast as C)

#48

Post by berntb »

mhansen wrote: post #2

Good article, but it seems to ignore the elephant in the room: the JVM's cold start times. For me, git's use case is being called from the command line, often interactively, between code editing sessions. It needs to start fast and finish fast, to not interrupt my workflow. The JVM's cold start times are huge. On the order of a second. Noticeably slow. So slow, that in the common case of committing a few files, the J…

Disclaimer: I'm very much not a Java/C# guy, so this might be totally barking up the wrong tree. :-)

Would it be a speed win to keep some JVM processes "half-started" if load and memory use allowed? The next started Java app will use one of the already half started JVMs.

You wouldn't need to do anything fancy to keep the JVMs around; if a half-started JVM wasn't used for so many seconds that it might be swapped out, you half-start another JVM and throw away the timed out one.

(Hmm.. I don't remember, but another process could take over stdin/-out/-err? Or you could just limit this to non-console applications.)

How much of the work time is in initializing the JVM and how much is specific for initializing the application? Could the JVM data structures (JIT etc) for an app be cached between runs?

Edit: Made a little clearer. Moved disclaimer to the top, so people know they can stop reading if I'm in the wrong forest..

Edit 2: I probably have read and unconsciously copied a similar idea that some Perl guy implemented?

Re: Why git is so fast (or why Java is not as fast as C)

#49

Post by zootm »

jerf wrote: post #38
axod wrote: post #15

>> "why Java is not as fast as C" Not actually true in reality. Modern JVMs can make on the fly optimizations based on the runtime profile, which would need to be done by hand in C. As said elsewhere though, Java excels when used for long running tasks - servers - backends etc where it can optimize for the long term. It doesn't excel when you try and start up the jvm loads of times for quick individual jobs. I don't…

You're bringing theory to a shootout based on facts. Hypothesizing that Java might be faster with a strong enough headwind doesn't make the actual, factual JGit run faster or C-git run slower. I mention this because programmers seem prone to this, and letting theory trump fact is a great way to make sure that you never learn anything.

It's a pretty specific shootout, of course; the reasons brought up for JGit's relative slowness are not issues present in most applications, they're specific to certain realms of system. Unsigned number support is a major headache about Java when doing low-level work, in particular.

I think it's also important to note that the slowness is relative to an incredibly fast C implementation - taking twice the time sounds painful, but in reality the pauses caused by Git are barely perceptible as-is, and double of that is not likely to be very annoying.

Re: Why git is so fast (or why Java is not as fast as C)

#50

Post by jrockway »

They use the word "high-level languages" and then use Java as the example. This is going to lead to some very wrong conclusions; the problems listed in the article are problems with Java, not problems with high-level languages.

I imagine a Git-in-Haskell would be very close in performance to the C git. (Then why is Darcs so slow? Because it uses an icky imperative, mutable model, whereas git uses a immutable functional model.)

Post reply on HN