[Openmcl-devel] slow read-char

Takehiko Abe keke at gol.com
Fri Jul 14 07:39:57 PDT 2006


Gary Byers wrote:

> It's also worth checking to ensure that the locking is really
> where the problem is.  That seems likely, but it'd probably
> be a good idea to run your test case through CHUD/Shark.

I run the chud-metering.lisp for the first time. Still don't know
how to read the result properly, but ccl::%unlock-recursive-lock
(8.0%), SPmkunwind (7.4%) and ccl::%lock-recursive-lock (6.8%) are
listed on the top.

***

> 
> The simplest way of avoiding it that comes to mind is to introduce
> thread-private streams.  I suspect (and this may vary a bit from
> person to person) that most application-level streams are only
> accessed from a single thread, and it might therefore be appropriate
> to make "thread-private" streams be the default.

I think the change would be nice -- I think it will be a boost
for some applications... But, nobody has mentioned that read-char
is slow before. So I'm not sure.

On the other hand, I guess that if one wants to access a stream
from multiple threads one has to lock it anyway regardless openmcl
does its own locking or not.


Thanks,
T.





More information about the Openmcl-devel mailing list