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

91–100 of 110 posts

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

#91

Post by tentonova »

kscaldef wrote: post #81
tentonova wrote: post #76

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

This still feels like the sort of statement that comes from having not worked with a (D)VCS that does branching well. There is no "inherent organizational complexity" in me having a private branch that I share with no one and which is only used for an hour or two while I work on a critical bug fix. What you're talking about seems to be multiple, long-running development or release branches. Those are hard to manage a…

This still feels like the sort of statement that comes from having not worked with a (D)VCS that does branching well.

I've worked with both git and hg.

There is no "inherent organizational complexity" in me having a private branch that I share with no one and which is only used for an hour or two while I work on a critical bug fix.

What's the value of this private branch beyond simply committing to the actual branch?

If it's just a bug fix, how big can it be?

If it's more than a bug fix, why am I hiding this code from the team by implementing it on a private, local, non-backed up, non-code-reviewed, non-centralized branch?

Typical branch lifetimes are more like hours or days, rather than weeks or months. There are exceptions, but by-and-large, branches are just used differently in git.

Why wouldn't I just commit this work incrementally to the actual upstream branch, rather than hiding it for "hours or days" from the rest of the team?

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

#92

Post by tentonova »

dasil003 wrote: post #80
tentonova wrote: post #76

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? 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 anyo…

In subversion, yes, you don't go through the hassle of creating a branch for all these reasons.

svn cp ^/trunk ^/branches/tentonova-bugfix-x

svn co ^/branches/tentonova ~/branch

I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here.

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.

Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication.

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

#93

Post by sid0 »

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…

> Anything but 'managed' -- while conceptually it covers things quite nicely, in practice it's used almost exclusively to mean "runs on the CLR"

Evidence? I know at least one Mozilla dev who calls JavaScript "managed". I call such languages "managed" too, and I write much more non-CLR code than CLR code.

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

#94

Post by prodigal_erik »

tentonova wrote: post #92
dasil003 wrote: post #80

Earlier quoted context omitted.

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

In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. svn cp ^/trunk ^/branches/tentonova-bugfix-x svn co ^/branches/tentonova ~/branch I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discre…

We do that, and I will say that svnmerge.py doesn't work very well with older versions of svn. A common failure mode is when you merge from trunk to rebase a dev branch and find a conflict, your edits to resolve it are automatically ignored and not reflected back to trunk, and any overlapping edits you make later will eventually cause new conflicts when you finally go to trunk.

Apparently the new svn:mergeinfo property helps, but we haven't migrated at work so I don't know how well.

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

#95

Post by wvenable »

axod wrote: post #59
jerf wrote: post #38

Earlier quoted context omitted.

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…

> Java isn't slower than C in general.

Really? In general? That statements seams worse than the original headline. Is Java faster than C for anything?

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

#96

Post by axod »

wvenable wrote: post #95
axod wrote: post #59

Earlier quoted context omitted.

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…

> Java isn't slower than C in general. Really? In general? That statements seams worse than the original headline. Is Java faster than C for anything ?

It completely depends. Both are silly generalizations.

Yes Java can be faster than C in some situations.

Can C ever be faster than assembly? Well, in theory no. But in practice, sometimes.

Depends if you're a master assembly programmer who hand optimizes everything.

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

#97

Post by barrkel »

delackner wrote: post #89
barrkel wrote: post #55

Earlier quoted context omitted.

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…

What meaning does "managed" have to you? I wasn't aware of a generic meaning. A virtual-machine-based language that happens to include garbage collection?

Generally it means type-safe and memory-safe, at least by default; is not usually precompiled (in practice precompilation is avoided for linking flexibility); and has a runtime which is at least nominally independent of the programs that run on it, e.g. that would need separate installation if not packaged as part of a larger environment.

The combination of type and memory safety usually requires a garbage collector, though it's not strictly necessary.

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

#98

Post by rbanffy »

axod wrote: post #96
wvenable wrote: post #95

Earlier quoted context omitted.

> Java isn't slower than C in general. Really? In general? That statements seams worse than the original headline. Is Java faster than C for anything ?

It completely depends. Both are silly generalizations. Yes Java can be faster than C in some situations. Can C ever be faster than assembly? Well, in theory no. But in practice, sometimes. Depends if you're a master assembly programmer who hand optimizes everything.

"Yes Java can be faster than C in some situations."

Unless the person writing the C implementation is grossly incompetent, I would like to see even one example for that.

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

#99

Post by dschobel »

zaphar wrote: post #78
dschobel wrote: post #70

Earlier quoted context omitted.

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.

Well as the github repo posted above you attests, there are (unsurprisingly) some non-trivial bugs in the last official release.

Unmaintained code is just not something I would ever use in a production capacity/rely on for my daily work. Especially considering the changes which have come to java and the jvm since 2005.

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

#100

Post by axod »

rbanffy wrote: post #98
axod wrote: post #96

Earlier quoted context omitted.

It completely depends. Both are silly generalizations. Yes Java can be faster than C in some situations. Can C ever be faster than assembly? Well, in theory no. But in practice, sometimes. Depends if you're a master assembly programmer who hand optimizes everything.

"Yes Java can be faster than C in some situations." Unless the person writing the C implementation is grossly incompetent, I would like to see even one example for that.

You can't see a situation where the JVM can optimize things, inline code, etc at runtime and beat a general C implementation? :/
Post reply on HN