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)

#61

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

barrkel wrote: post #11

I find it interesting to read that every single one of his criticisms of JGit would not need to apply to a C# implementation. Unsigned types, unmanaged memory allocation (Marshal.Alloc ), unsafe code with pointers, native P/Invoke access, value types (e.g. fixed arrays for his SHA-1 point), and an IDisposable convention for managing all the unmanaged trickery, C# has pretty much all the needed features. When optimizi…

I actually believe they're accessible in Java as well through JNI and JNA. But I'm hardly a Java expert.

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

#62

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

In strictly language terms, C will always be faster than Java. However, I would dispute that one could say on a general basis that C programs will always be faster than Java programs.

In fact, I would argue that all things being equal, the Java program is more likely to be faster (and yes, I realize there are a metric ton of potential caveats to what I just said). Why? Because Java allows you to focus on the "big picture" optimizations that really make all the difference.

On the other hand, given an infinite amount of development time and experienced developers, the C program will likely be much faster. In some cases this is necessary. But for most cases, I personally would rather just ship something than try to squeeze every ounce of efficiency out of it.

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

#63

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

JulianMorrison wrote: post #60

axod wrote: post #56

Earlier quoted context omitted.

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 def…

Yeah I just don't work that way. I work linearly :/

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

#64

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

adw wrote: post #40

kelnos wrote: post #31

Earlier quoted context omitted.

I'm actually a bit curious as to why they're using JGit as a git server. Is there something lacking in git-daemon, etc.?

Most likely they can drop it into their existing systems for deploying Java apps.

As well as use it as a library API, and integrate it with their other libraries/services/etc.

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

#65

Post by Locke1689 » Sat, Jan 02, 2010, 6:09 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…

You have a good point, but I don't think I asserted that any of those points are correct. I mostly agree with JulianMorrison on this one, although I think sometimes you can see performance bottlenecks coming. If you know an inner loop needs to be faster than your interpreted language can normally do, you might as well write that segment in C or ASM from the beginning. Mercurial still seems to me like a good example of optimization done correctly.

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

#66

Post by berntb » Sat, Jan 02, 2010, 6:11 PM UTC

mrkurt wrote: post #58

berntb wrote: post #41

Earlier quoted context omitted.

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.

OK, a point; the pain with compiling languages is the compile cycle where you edit-and-run just local tests, not for the whole system.

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

#67

Post by SapphireSun » Sat, Jan 02, 2010, 6:50 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…

There is an intermediate state where you make it "just work" but design it so that it's easy to speed up the algorithms later. Premature optimization makes you waste time on dumb stuff, but leaving yourself a way out is a lot less costly than optimizing everything and lets you avoid the problem you mentioned.

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

#68

Post by gruseom » Sat, Jan 02, 2010, 6:51 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…

Wow, did you ever hit the nail on the head. I've been saying this for a long time (edit: e.g. http://news.ycombinator.com/item?id=96186, http://news.ycombinator.com/item?id=173949), wondering why I'd never run across anybody making what seems an obvious point. At last I have!

The important decisions around performance have to do with design, not optimization. Knuth's original principle was quite explicit: forget about most small efficiencies. But people commonly use it to justify not thinking about large ones. "Don't micro-optimize prematurely" somehow got changed into "don't think about performance until the end of the project".

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

#69

Post by dasil003 » Sat, Jan 02, 2010, 7:04 PM UTC

axod wrote: post #63

JulianMorrison wrote: post #60

Earlier quoted context omitted.

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 def…

Yeah I just don't work that way. I work linearly :/

What type of work do you do that you never have urgent bug fixes and/or never have features that take more than a day to complete?

Sure it's optimal to work linearly, but in the real world things come up. Now if you are looking for a reason to tell stakeholders to suck it up and wait, then poor branching support may help you, but that's a technical solution to a managerial problem. If you're interested in having the most flexibility to solve real world problems, then git's power is indispensable. Hell, you can work linearly all the time, and retroactively convert anything into a branch. Even if you don't need branches. Even if you are the sole developer.

Sorry if that's a little harsh, but statements like "My point is, if you want lightening fast rev control for some reason, probably better to not use distributed." smack of willful ignorance. Go use git for a while and then come back and try to say that with a straight face.

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

#70

Post by dschobel » Sat, Jan 02, 2010, 7:04 PM UTC

jwinter wrote: post #54

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

I was looking at this the other day and am concerned that it hasn't been updated since February, 2005. That's practically ancient in terms of software.