On Fri, 2010-10-22 at 17:25 -0400, Steve Litt wrote: > > =========================================== > “We should forget about small efficiencies, say about 97% of the time: > premature optimization is the root of all evil. Yet we should not pass up our > opportunities in that critical 3%.A good programmer will not be lulled into > complacency by such reasoning, he will be wise to look carefully at the > critical code; but only after that code has been identified” > ===========================================
I would agree with that up to the exponential factor of 3% times your user base ;) Also I am not talking about breaking down into assembler and getting ridiculous with extreme optimization or going really low level. Which many still do even in C, when C is not fast enough ;) > Optimize what makes a difference, and only what makes a difference. I agree, and thus recoding java-config in C and other tools. I am not recoding Portage in C, or coding everything in C. Though maybe some day if I get really proficient in C. > But here's the facts. There's not a typist on earth who can outrun UMENU on a > modern computer running Linux. From the typist's view, UMENU's response is > instantaneous. So tell me one more time just so I understand -- why should I > make it faster? Does it make a user wait at all for any amount of time? How many users of that application are there? Multiply the delay by the amount of user, and see if that maybe is justifiable for porting to a more efficient language or recoding. > Now let me enumerate the advantages of Perl over C: Whats Perl written in? One could say Perl was created so you didn't have to learn or code in C. Or maybe to do things not possible in a shell script, not to do with C. One could also say Windows exists do you don't have to learn the command line, just how to move and click a mouse. > But in the following situations I'll use Perl over C every time: > > * Speed bottleneck is the user's response Not clear on that one, if you mean users response to Perl being a bottleneck vs C. Well they are correct, if the bottleneck has any noticeable effect as in a delay. > * The process is done *rarely*, and the difference is 2 seconds vs 2 minutes Times how many users losing 2 seconds? > * A better, simpler, faster algorithm can be found Simpler yes, better arguable, faster maybe in some situations > * For whatever reason, the Perl program's speed is "fast enough" And allot of times that is good enough. ASSP is fast enough for me for now in Perl. Also I haven't the time or interest in cleaning up that mess and porting it to C. But for my asspr, I went straight to C, after some massive nasty shell scripts, kinda like you mention below :) > I haven't run this for a long time because my web host made it hard to ftp > down raw logs, but as I remember this took about 10 minutes for a couple > months worth of log, which was acceptable to me. But if it hadn't been > acceptable, I then could have either optimized the algorithm or rewritten > part > or all in C, after seeing how well it ran. That so reminds me of what I had before to replicate asspr's functionality. I thought the delay was acceptable, much less usage of resources. Given Bash, grep, awk, the commands I was invoking like you being written in C. However each has its own overhead, memory allocation etc. My bash + unix programs was like a turtle compared to my rabbit asspr. That 10 minutes might seem reasonable, till a C program does it in less than 1 and with a fraction of the overhead. End of the day its up to each to decided. I just do not like that someone else decided and coded stuff in a language that was efficient for them at the time. That has been wasting my time and resources ever since. Much less who knows how many others ;) -- William L. Thomson Jr. Obsidian-Studios, Inc. http://www.obsidian-studios.com This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. --------------------------------------------------------------------- Archive http://marc.info/?l=jaxlug-list&r=1&w=2 RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml Unsubscribe [email protected]
