chicken-users
[Top][All Lists]
Advanced

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

[Chicken-users] chickenlib/select, custom ports and performace drains


From: Joerg F. Wittenberger
Subject: [Chicken-users] chickenlib/select, custom ports and performace drains
Date: 03 Jan 2003 15:39:47 +0100

Hi Felix and Tony,

a) find attached a small fix to socket.scm fixing the version in
chickenlib which doesn't properly check for short writes

b) an urban legend goes "chicken is faster than rscheme", which
apparently refers to the virtual machine they implement.
Unfortunately there is more than just a VM and this practically kills
the advantage.  When I ask http://www.askemos.org/README it easily
saturates my DSL link (16KB/s) at a steady rate.  If ask the chicken
version over the same link I get 1-20KB/s.  There appears to be a
fixed delay at random time and duration, but most often while the
network port is closed and the log file entry is written. Then nothing
is sent over the net.  This delay defeats fair comparison, but the
chicken version feels already slower before.

c) The implementation uses custom ports.  Those don't support
accumulation/flushing of output, as god intented.  Hence Tony had to
resort to byte size write(2)'s... This easily explains heavy delays.

d) I'd be grateful if modifications could implement custom ports as a
class - or would it be expensive?  Than we could easier derive some
more specialized ports.

e) Something could be done about the select call.  If I understand
everything correct (not 100% sure) then the timeout in the select call
will block the process for a while.  This would explain why I observe
a maximum load of 0.84 when the Server should be full loaded.
Unfortunately I have not enough jobs for that much processing power.
The constant poll also keeps a rest load (bad for laptops).  What
would be the implications to used "no timeout" + "sigpipe"?

f) How can I get gc statistics?

Best regards

/Jörg

-- 
The worst of harm may often result from the best of intentions.

Attachment: diff
Description: socket.scm


reply via email to

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