> > Anyone care to explain why PicoLisp only got second place? :-)
> if they measured "The way to do it", picoLisp would be 1st:-D
In a certain way, yes. The "client simulator" that was used in the
contest was rather dumb, it simply sent a stream of requests to the
server. These requests, of course, didn't take advantage of some
features of the PicoLisp framework, like direkt passing of DB objects in
URLs. Instead, all objects had to be looked up via indexes. Or, all
pages had to be represented by files, because the "@function" URL syntax
(which can also considerably speed up accesses) was not used by (or even
known to) the simulator.
The major reason, however, was a serious bug in PicoLisp at that time.
We found it at SmApper, some time after the contest, when importing data
from a large number of processes.
The bug was that after the select() system call only the first available
file descriptor was serviced (instead of *all* that were available).
This results in a dramatic performance degrade, and also losses of
requests, as the higher file descriptors were never serviced at high
> I would speculate: one limiting factor might be the forking http
> server (it should be simple to test how many requests per second I can
I would say that this was not a bottleneck.
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]