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

21–30 of 110 posts

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

#21

Post by DougBTX »

axod wrote: post #20
thibaut_barrere wrote: post #14

From the last line: "But, JGit performs reasonably well; well enough that we use internally at Google as a git server." Rings the 'good enough' bell to me.

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

Discussing bottlenecks oversimplifies, it assumes everything goes down one pipeline. Small changes can make big differences. If your tool feels a little bit snappier, you might make two commits instead of one, then six months down the line someone saves half an hour tracking down a bug because the blame messages are more relevant.

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

#22

Post by fauigerzigerk »

Of the three issues mentioned in the post Java's lack of value types is the important one in my view. That's what causes Java programs to use hugely more memory than C, C++, C# or Go programs. Using more memory translates into an orders of magnitude drop in performance for memory intensive applications.

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

#23

Post by 10ren »

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…

Run the java app as a server.

I did this with javac, and went from 5000ms (ant) to 200ms (averages). It gets faster each time it runs, enormous speedup after the first run; but still very significant for the next 10; and continuing at a slower rate from then on.

The client needs to be non-java, to avoid the startup cost there. I run it as a console, so that is the "client" (wrapped in rlwrap, for filename completion/editing etc). My workflow is to compile in a separate shell; that's why I did it this way.

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

#24

Post by ssp »

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.

"Computers these days" have always been fast; if that were an argument for anything, performance would not matter at all anymore.

If computing power is fungible, then a 10% performance improvement translates into a 10% saving on the hardware budget. This matters for data centers, and it matters for embedded systems where using a slightly cheaper component in a million devices might mean saving a million dollars.

I think the fallacy of the fast, modern computer comes from the fact that PCs are not very fungible at all; they come in discrete performance steps. And since your application is pretty unlikely to be the most demanding one, it will probably run just fine even without much optimization.

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

#25

Post by blasdel »

barrkel wrote: post #17
DarkShikari wrote: post #3

This has always been true and will continue to be true. It's possible to build a high level language that's as fast as C? Sure--but only if you restrict the programmer to the same amount of effort in both languages. If your application is one where it's worthwhile applying a great deal of extra programmer time in order to improve performance, a low level language will always win because it exposes more of the native…

Of course, managed languages can buy you other things, such as inlining indirect method calls by rewriting the call site (polymorphic inline caching), dynamic profile-guided optimization, not to mention the fact that garbage collection is often faster than manual deallocation, depending on the nature of the problem and the pattern of allocations. (Of course, design of managed applications can benefit greatly from awa…

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.

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

#26

Post by JulianMorrison »

axod wrote: post #20
thibaut_barrere wrote: post #14

From the last line: "But, JGit performs reasonably well; well enough that we use internally at Google as a git server." Rings the 'good enough' bell to me.

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

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.

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

#27

Post by barrkel »

blasdel wrote: post #25
barrkel wrote: post #17

Earlier quoted context omitted.

Of course, managed languages can buy you other things, such as inlining indirect method calls by rewriting the call site (polymorphic inline caching), dynamic profile-guided optimization, not to mention the fact that garbage collection is often faster than manual deallocation, depending on the nature of the problem and the pattern of allocations. (Of course, design of managed applications can benefit greatly from awa…

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.

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

#28

Post by JulianMorrison »

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…

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.

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

#29

Post by Deestan »

axod wrote: post #20
thibaut_barrere wrote: post #14

From the last line: "But, JGit performs reasonably well; well enough that we use internally at Google as a git server." Rings the 'good enough' bell to me.

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 for a clean build now takes ~1 hour. True story. :(

Luckily, enough of us got so annoyed about this that it got fixed after a few weeks of dedicated effort. We now have a constant conscious effort to keep build times down.

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

#30

Post by axod »

JulianMorrison wrote: post #26
axod wrote: post #20

Earlier quoted context omitted.

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

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 server could do the heavy lifting (Wether this happens in practice is another matter). My point is, if you want lightening fast rev control for some reason, probably better to not use distributed.

Post reply on HN