Re: [Chicken-hackers] slow polling

[Jörg F . Wittenberger]

Hi folks,

IMHO the patch in
http://lists.nongnu.org/archive/html/chicken-hackers/2016-02/msg00032.html
SHOULD be applied - it fixes a serious bug.

The modified scheduling policy may be considered once 4.11 is out.
Switching the timeout queue to a priority queue still looks as if it is
worth it.  But...code complexity.


The rest may be a read herring.  Almost that is.  There is definitely
something measurable to gain, but it is little - not worth the
additional build-time complexity.  At least not yet at this time[1].



This throws me back to the drawing board.  How do I figure out where
chicken spends those 30% additional runtime 4.9 did not?  Any clue
appreciated.


Cheers

/Jörg


[1]  I have a working version of those modifications here.  Now I
understand that the repeated re-creation of the fdset is because it
needs to be compatible with the select(2) based version.   Alternatively
(as I submitted the code) we need to conditionally compile scheme code
on NO_POSIX_POLL - apparently I'm not the only one who does not know how
to do that.


Am 19.02.2016 um 18:46 schrieb Jörg F. Wittenberger:
> Am 19.02.2016 um 14:02 schrieb Jörg F. Wittenberger:
>> 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 opened ticket 1259 for this.
> 
> To make the kind reviewers job easier, I'll post diffs in piecemeal here.
> 
> Details to follow below.
> 
> Cheers
> 
> /Jörg
> 
> To follow the related changes:
> 
> 1. Apply
> 
> http://lists.nongnu.org/archive/html/chicken-hackers/2016-02/msg00032.html
> 
> this should just fix a bug
> 
> 2. Apply
> 
> http://lists.nongnu.org/archive/html/chicken-hackers/2016-02/msg00033.html
> 
> 3. Apply the attached patch.
> 
> This only adds comments:  Section headers large enough for "meld" at
> least to pick up the difference.  (To both the original and master.)
> You want this to make head or tail of the upcoming changes.  Eventually
> there will have to be a cleanup diff to get rid of them.