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)

#71

Post by ajross » Sat, Jan 02, 2010, 7:14 PM UTC

wglb wrote: post #52

DarkShikari wrote: post #7

Earlier quoted context omitted.

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.

But that's just saying the same thing. The point being made above is that working "correctly" simply isn't enough if performance is a design goal too (or rather, correct operation requires that the software meet the performance goals at design time). So if you start out working on only half the problem, you'll still fail.

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

#72

Post by ajross » Sat, Jan 02, 2010, 7:17 PM UTC

richardw wrote: post #45

bad_user wrote: post #34

Earlier quoted context omitted.

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.

The linked article actually shows quite a few non-trivial optimizations already being done in JGit (e.g. storing an SHA-1 in 5 ints to avoid the extra heap block). I'd be surprised if they got much farther than they are, honestly.

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

#73

Post by houseabsolute » Sat, Jan 02, 2010, 7:22 PM UTC

One thing I have been wondering as a non-git user: is git really CPU-bound in most operations? Maybe someone who is a regular git user can answer me this question. If it's not, I wouldn't expect Java to matter too much to its performance.

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

#74

Post by pronoiac » Sat, Jan 02, 2010, 7:48 PM UTC

berntb wrote: post #48

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

Apache in pre-forking mode might have inspired you. High availability Java might be relevant.

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

#75

Post by barrkel » Sat, Jan 02, 2010, 7:59 PM UTC

j_baker wrote: post #61

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.

Not at the same level of abstraction, IMO. To take a representative example, pointer arithmetic simply isn't really available to you from Java, unless you pretend your integers are pointers and go through JNI functions for indirection, etc., which is going to be slow enough to defeat the purpose.

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

#76

Post by tentonova » Sat, Jan 02, 2010, 8:01 PM UTC

dasil003 wrote: post #69

axod wrote: post #63

Earlier quoted context omitted.

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…

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?

I've always worked to constrain non-linear development to the absolute minimum required because the technical costs are easily dwarfed by the human communication overhead and inherent organizational complexity engendered in multiple disparate branches of development.

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

#77

Post by axod » Sat, Jan 02, 2010, 8:15 PM UTC

dasil003 wrote: post #69

axod wrote: post #63

Earlier quoted context omitted.

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…

I have many features that take more than a day to complete, but I prefer to do them in such a way that it doesn't break other stuff. That's just the way I prefer to work. If I'm working through a big arch change, I'll do it in sections, each time making sure everything builds and works and is sane. I checkin often, once I hit something that builds+works.

That's just the way I work.

Similarly, I don't use threads in programs unless I absolutely categorically have to. It's a similar sort of thing. Call me crazy :/

I did use git for a bit, and thought 'meh'. It didn't solve any real world problem I had.

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

#78

Post by zaphar » Sat, Jan 02, 2010, 8:34 PM UTC

dschobel wrote: post #70

jwinter wrote: post #54

Earlier quoted context omitted.

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.

and yet it functions perfectly with no problems when I use it in the VimClojure plugin. Tex hasn't been "updated" in ages either yet its fully functional. Sometimes software is just done and no further activity is needed. Judge it on whether it works not the date of the last commit.

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

#79

Post by xsmasher » Sat, Jan 02, 2010, 9:44 PM UTC

JulianMorrison wrote: post #28

DarkShikari wrote: post #7

Earlier quoted context omitted.

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…

I always though that what that one quote meant was: measure, then optimize. It's no use tuning the hell out of a function that hardly features in your profiler results.

That, and also optimizing code that later gets thrown out entirely because requirements or other factors change. There's no benefit to optimizing code that goes in the bit bucket.

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

#80

Post by dasil003 » Sat, Jan 02, 2010, 9:57 PM UTC

tentonova wrote: post #76

dasil003 wrote: post #69

Earlier quoted context omitted.

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…

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? I've always worked to constrain non-linear development to the absolute minimum required because the technical costs are easily dwarfed by the human communication overhead and inherent organizational complexity engendered in multiple disparate branches of development.

Of course, but that's irrelevant to the utility of git branches. In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. In git though, branches are most commonly used within one developer's workflow. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyone unless you have good reason to.