Re:A fun optimization trick from rsync
by vortico on Sunday October 28, 2018 @11:56PM
(#18324944)
I don't like it. You should put the logic where the logic should be, so it's clear to see what was intended.
[ Parent
| on HN ]
In case performance is all you are after, this has much less potential for inlining than the rsync implementation has.
True, but for rsync's case of setting the mtime of a file, performance of this logic is utterly insignificant.
"Everything is fast for small n." -Knuth.
While syncing some million files, I'm sure it'll have an impact tho.
P.S.: Yes, we use it for a million files, regularly.
it's probably not noticeable for a million files
the syscall is going to be many, many orders of magnitude slower than the difference between a direct and an indirect call
IIRC, switch statements bigger than a certain sizes are compiled to jump tables. So it's just a static jump after the code finds a working method.
In theory, it's a very cheap piece of assembly after that point.
With trivial method() functions, you could speed through that loop a million times in a millisecond.
If all of the methodFuncs fail, this will attempt to jump to whatever address happens to be in memory after the last element of methodFuncs. You've forgotten to stop iterating.
There is a terminating NULL at the end of the array to stop the iteration.
Re:A fun optimization trick from rsync
by jbverschoor on Monday October 29, 2018 @06:01AM
(#18326198)
oh my... that never went wrong
A terminating null element or logical equivalent in an array is helpful in lots of situations. As one example it simplifies the logic of looking for an element in an array and performing some special operation if it was not found. No bool found variable necessary.
Re:A fun optimization trick from rsync
by jbverschoor on Monday October 29, 2018 @10:56AM
(#18327986)
Well yes, but it can easily be removed by accident, and is easy to oversee. See the parent comment