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

[Jörg F . Wittenberger]

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
> pointless,

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
steps.

> 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
beginning.)

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

/Jörg