[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] two minor tweaks to runtime.c

From: Jörg F . Wittenberger
Subject: Re: [Chicken-users] two minor tweaks to runtime.c
Date: 29 Sep 2011 14:44:09 +0200

On Sep 29 2011, Alaric Snell-Pym wrote:

On 09/29/2011 12:38 PM, Jörg F. Wittenberger wrote:

I don't not have benchmarks for a reason: they would cost me too much
time to do right.  Personally I don't believe too much in benchmarks
anyway.  I believe in fast execution and source code review.

Ah, but how can you measure fast execution without a benchmark?

Well, at the end of the day I run some complex applications.
For instance I use httperf.

I don't touch chicken, if I did not find a reason to do so.
It complicates my work.

Or let me take the threading problem I solved ages ago. I did NOT want to get into that business. All I wanted was to have my prog run on chicken as it did on rscheme. Benchmarks said chicken is faster at that time. What a lie a benchmark can be! It was crawling slow. Tracked that down to the timeout queue. Fixed the complexity issue. Problem solved. Hm. So how would I device a benchmark case for that one?

If the supposed performance improvement can't be benchmarked, then it's

Hey, I wrote "crawling slow"!  That's worse than just a benchmark.
If the same program needs seconds instead of a fraction, then I don't
bother.  I tracked the problem down, fixed a single thing and found
a huge speed up.  As expected.  Case was closed for me: goal reached.

At that time there was no point in perfomance measurements.

Later I wrote that httperf run into my Makefile.  At that time I recall
for a fairly complex page 8-12 replies per second.  Same page now around
24 per second.  No single reason for that.  Just accumulated, incremental

the system. Decent benchmarks can be put into the test suite, so future

Sure.  But since I'm working on a different front, I just don't have
the capacity to invest into advertising here.

If something works better for me than the current state of affairs,
then I notify the list.  Code review is due upon integration anyway.
And those who do have benchmarks already are welcome to post their
results.  Reviews are welcome to challenge the code.

derived directly from applications, and include representative mixes of
operations to test overall performance as well as low-level
per-operation benchmarks!

OK, see above.  My benchmark (httperf) fits perfectly.  Except it is flawed:
the code has evolved in that time too.
(In fact it has grown: sqlite/pthread interaction was not included in the

So we are back at the capacity issue again: I have only so much live
time.  I'm not ready to spent it maintaining benchmarks in the hope
that those will eventually convince someone to benefit from the work I did.
You are free to convince yourself.

Best Regards


reply via email to

[Prev in Thread] Current Thread [Next in Thread]