Why git is so fast (or why Java is not as fast as C) • Hacker News Board

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

#51

Post by gvb » Sat, Jan 02, 2010, 2:46 PM UTC

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…

As Deestan notes, delays have direct multipliers. Beyond that, delays often have indirect multipliers that are even worse.

XKCD "Compiling" http://xkcd.com/303/ is funny because we have all done it. If there is a noticeable lag in a development step (VCS operations, compiling, running the program, etc.), it is very likely that the developer will lose concentration and switch to reading email, browsing HN, reading /., BSing with co-workers, etc.

This takes the direct delays and turns them into exponential multipliers. The result is that 30 seconds of lag has a high risk of becoming 30 minutes of wasted time.

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

#52

Post by wglb » Sat, Jan 02, 2010, 3:04 PM UTC

DarkShikari wrote: post #7

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.

Slightly tangential, but I think "Premature optimization is the root of all evil." is the most misquoted statement in the history of computer science. Most importantly, people tend to misinterpret "premature" to mean "any time before the software is done" or similar. I can't even count the number of times where I've worked on or watched a project where performance is important and the following series of events occur…

That is why the rewording I use is "First make it right, then make it fast". If you make it fast first, then that is premature optomization.

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

#53

Post by ido » Sat, Jan 02, 2010, 4:11 PM UTC

berntb wrote: post #41

Deestan wrote: post #29

Earlier quoted context omitted.

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.

C++ compiles much slower than many other popular compiled languages, and the more of its "fancy" features you use the slower it compiles.

C & Java for example both compile much faster than c++.

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

#54

Post by jwinter » Sat, Jan 02, 2010, 4:14 PM UTC

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…

Check out nailgun if you're interested in using the JVM as a command-line tool without a cold-start.

http://martiansoftware.com/nailgun/index.html

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

#55

Post by barrkel » Sat, Jan 02, 2010, 4:20 PM UTC

blasdel wrote: post #43

barrkel wrote: post #27

Earlier quoted context omitted.

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…

I don't use it to exclusively mean CLR-hosted, and to be frank, I think the meaning is pretty clear outside of MS contexts. I believe "GCed" focuses too much on the memory allocation strategy; which while important for many of the practical advantages of managed languages, I think it ends up lopsided.

Finally, more people using a word in an alternative way is the path to controlling its meaning, rather than avoiding the word altogether, cf "queer" and the like.

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

#56

Post by axod » Sat, Jan 02, 2010, 4:56 PM UTC

DougBTX wrote: post #47

axod wrote: post #30

Earlier quoted context omitted.

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.

No. I prefer to keep things simple, always make sure the source builds, and just develop linearly where possible. I think it makes for cleaner workflow.

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

#57

Post by steveklabnik » Sat, Jan 02, 2010, 4:58 PM UTC

igouy wrote: post #42

rikthevik wrote: post #10

Earlier quoted context omitted.

...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?)

That is what the study said. It holds constant across languages and tools.

Now, if I could find a link for you, that'd be awesome. My google-fu is weak today.

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

#58

Post by mrkurt » Sat, Jan 02, 2010, 5:02 PM UTC

berntb wrote: post #41

Deestan wrote: post #29

Earlier quoted context omitted.

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.

Most sane projects I've experienced do "builds" even with scripting languages. It's every bit as much of an annoyance to have a bunch of needlessly slow tests as it is to deal with slow compile times.

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

#59

Post by axod » Sat, Jan 02, 2010, 5:10 PM UTC

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.

I was countering the headline, which wasn't correct. Java isn't slower than C in general. It may be in specific cases, for specific programmers, etc but that's not what the headline stated.

The title takes one specific application in a particular niche, used in a certain way which a particular programmer can't get to run fast enough, and concludes that Java isn't fast enough. Faulty logic.

The argument about JGit vs C-git for me isn't something I feel you can learn anything from.

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

#60

Post by JulianMorrison » Sat, Jan 02, 2010, 5:15 PM UTC

axod wrote: post #56

DougBTX wrote: post #47

Earlier quoted context omitted.

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.

No. I prefer to keep things simple, always make sure the source builds, and just develop linearly where possible. I think it makes for cleaner workflow.

The advantage of having lots of small branches is that you isolate work. You never have the problem of wanting to fix a bug or add some small feature, but having the code all in a mess halfway through a major reorganization.

Also it's a lot easier to try something experimental on a branch. If it works, merge it in. If it fails, abandon the branch.

Git makes branching and merging fast enough that using them as the default workflow makes sense.