News for hackers. Stuff that matters.
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.

    typedef int (*MethodFunc)();

    void doMethod() {
        static int methodId = 0;

        static const MethodFunc methodFuncs[] = {
    #ifdef METHOD_1_CAN_COMPILE
            method1,
    #endif
            method2,
            ...,
            NULL
        };

        while (methodFuncs[methodId]) {
            int success = (methodFuncs[methodId])();
            if (success)
                return 0;
            methodId++;
        }

        return -1;
    }
Re:A fun optimization trick from rsync by blux on Monday October 29, 2018 @04:00AM (#18325725)
In case performance is all you are after, this has much less potential for inlining than the rsync implementation has.
Re:A fun optimization trick from rsync by vortico on Monday October 29, 2018 @04:09AM (#18325760)
True, but for rsync's case of setting the mtime of a file, performance of this logic is utterly insignificant.
Re:A fun optimization trick from rsync by bayindirh on Monday October 29, 2018 @07:41AM (#18326631)
"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.

Re:A fun optimization trick from rsync by blibble on Monday October 29, 2018 @07:48AM (#18326676)
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

Re:A fun optimization trick from rsync by bayindirh on Monday October 29, 2018 @02:40PM (#18330008)
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.

Re:A fun optimization trick from rsync by vortico on Monday October 29, 2018 @12:04PM (#18328593)
With trivial method() functions, you could speed through that loop a million times in a millisecond.
Re:A fun optimization trick from rsync by stouset on Monday October 29, 2018 @02:45AM (#18325486)
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.
Re:A fun optimization trick from rsync by ahoka on Monday October 29, 2018 @03:27AM (#18325599)
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
Re:A fun optimization trick from rsync by dsamarin on Monday October 29, 2018 @07:32AM (#18326588)
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