[Chicken-hackers] slow polling

[Jörg F . Wittenberger]

Hi folks,

I guess I found the reason, why my 4.9.1 based chicken is about 30%
faster in practice while master performs better on all little load and
unit benchmarking.

Observing that my version has a rather small deviation from the median,
while master has extremely fast and extremely low values, this has
either to come from some "rare", but extraordinary expensive operation.

Turns out to be a regression.  When I submitted the polling code, it was
a little complex, that's true.  But it was carefully crafted and well
tested.  It went to the trouble to keep the fd-list in synch with the
poll/select set.  For the only purpose to be sure the poll(2) ends up in
practice to be just that, call poll.

When it was integrated into core, it was rewritten to used this - sorry,
but IMHO brain dead - approach to re-create the fd set from the fd list
each time each time we check.

Now I see the low load case to be almost 50% faster and the old code to
be 30% faster and more stable on delivering responses.  I have no idea
what the combined effect would be.

How do we deal with this?  I don't want to keep maintaining my own "fast
chicken" branch.  But I can't convince myself to switch to master.
Waiting almost 3 seconds for my browsers start page was already
bordering on pain.  Switching 4-5 is no option.  There are other users
too.  I'd like to get this into core.  It's working for years.  But it's
going to be a huge change.  Basically most of scheduler and some code in
srfi-18 is affected.

I suppose: not before 4.11 - but who's going to review the patch?  (I
did not yet prepare it.  It's just the question what I'm whether I'm
working on "my branch" and ignore whatever or attempt to produce the
smallest diff to ease the review.  The latter being more work and only
helpful within a small enough time window.)

Cheers

/Jörg