[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