On Thu, Mar 14, 2002 at 03:15:02PM +0700, John Indra wrote:
> On Thu, Mar 14, 2002 at 07:40:04AM +0100, Poul-Henning Kamp wrote:
> This is not just talking about benchmarks. This situation will probably make
> people conclude things that are not beneficial at all for FreeBSD. People in
> my definition are non-C-coders and those-who-just-like-to-generalize-things.
> Exclude me from that list, but there are many of others who fit to that
You have to realize that incompetent programmers will always find a way to
hog a system down. When you write any piece of software, you have to make
tradeoffs, which must be in favor of the most common usage. You can't expect
FreeBSD to be optimized for a degenerate loop.
Now, your point is that, this is just a simple benchmark but even real apps
show slowdowns. This point is moot, IMHO: it simply goes to show that their
author, no matter how widely known or experienced are, are doing something
silly. There are endless examples of bad programming practice in the free
software community (go have a look at some code from Crispin - and teach
him what strcmp is for!). And if you wrote the code yourself, you might
take the hint that something might be wrong in your code, not the OS.
In this particular case, optimization is particularly simple - pre-extend
the $result string to the maximum size you expect you'll be (reasonably)
using. This results in a run time of 13 seconds on my lowly laptop.
The problem is that people often think that programming in Perl (or Java,
or Visual C++, take your pick) means you don't need to know what goes on
under the hood. This is simply not true.
The fact the Linux seems to behave better under some degenerate circustances
is non-conclusive at best - each software writer gets to pick what they
optimize, like in people optimizing for benchmarks etc.
If Bill Gates had a dime for every time a Windows box crashed...
...Oh, wait a minute, he already does.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message