Premature Optimization is the Root of All Evil (was Re: Ovidian Transform)

[chip]

Why try to speed up something that you don't know is responsible for your speed problems? Even more, why try to speed up something if you don't know you HAVE speed problems?

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason -- including blind stupidity.
    -- W. A. Wulf, "A Case Against the GOTO"

Words to live by.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

[jcwren]

I really have to go with chip on this one. I played around with optimization for about 1/2 an hour and found that nothing I could do affected the performance by more than 1% or so.

I did not have as much time as I would have liked to spend on it, so I did not run profiling tools on that section, nor look at the actual code generation. I focused on that small section because I have a lot of experience with C, and frequently have to do optimizations of that nature because of the microcontrollers I work with (microcontroller compilers typically produce far worse code than GCC, since GCC benefits from a wide developer base, and most microcontroller compilers are 1 to 5 person shops).

My other interest in speeding it up was a trade off with making it fewer lines. Those 12 or so lines just seemed nasty. If it can be reduced to fewer lines, it often becomes more maintainable. Given that, I have the following replacement:

SV* get_date (char* str)
{
    char new_date[9]; 
    while (*str++ != '|');
    memcpy (new_date, str+4, 4);
    memcpy (new_date+4, str, 4);
    return newSVpv(new_date,8);
}

Normally, Inline::C uses -O2 optimization, which is fairly agressive about fragments like that. It's smart enough to recognize that memcpy()s can be replaced with several instructions if the length to move reduces to a compile time constant.

One would question if the above is actually more maintainable, since the byte copy of new_date[0] = date[4]; is more indicative of what the operation is intending to do. If one is aiming for speed and readability, the new_date[0] = date[4]; relies more on the working knowledge of the compiler.

No matter what the case, this isn't really the area that needs work to speed this puppy up.

--Chris

e-mail jcwren

[hsmyers]

Well the snap answer is “Why not?” But more to the point why write code that is less efficient than need be? In fact, you can't even get away with the canonical 'lazy' as a reason, since what I wrote takes less typing. And the declaration of an un-needed variable doesn't do a whole lot for clarity—particularly in a routine which already has the potential for confusion, i.e. the two container arrays, where the second is used for the cross-wired transfer, something that might at casual glance seem a puzzle. So since it is clearer, faster, and shorter, I'd argue a win! Re: Mr. Wulf, nice quote, but in this context it somehow reminds me of

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. – Ralph Waldo Emerson “Self Reliance”

–hsm

"Never try to teach a pig to sing…unless of couse if it's New Year's Eve! Happy New Year to All!."

[chip]

I think you're arguing against a point I didn't make. (Though, in fairness, I might have been arguing against a point you didn't make.) I didn't suggest that optimization was unimportant or even undesirable; rather, that given a program almost entirely written in Perl, there's usually no point in speeding up the C bits. The key word is "usually", BTW; my main point is that optimization should only be attempted when profiling shows that the effort will be rewarded.

UPDATE: The following complaints are wrong; please ignore them. I've left them here for hysterical raisins, and so replies don't seem confusing.

BTW, you don't help your case when you use punctuation marks that are neither ASCII nor Latin-1; it makes your comments hard to read. Let me guess: You're using Windows, right? You ought to look at your comment from a Unix system; it has lots of question marks where they don't belong.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

[hsmyers]

You are right, I've no argument with things stated that way!

Now on to the important stuff! Regards punctuation, I'm at a loss on this one, as other than ASCII, I've no way of entering the mystery marks into the message. Perhaps you may mean my overuse of HTML? Things like mdash, hellip, ldquo and rdquo with the occasional ndash are pretty much second nature to me. Note that here I've used them without the preceding ampersand and the trailing semi-colon. If these show up as question marks then maybe I can use you as a g-pig to test the numeric version to see if that works on your side of the fence? Could you try adding the decoration to this stuff in your environment and see what happens?

–hsm

"Never try to teach a pig to sing…it wastes your time and it annoys the pig."