[Openmcl-devel] slow read-char
keke at gol.com
Fri Jul 14 22:52:27 EDT 2006
> Hi Takehiko -- you are not alone!
> I recently experienced performance problems using READ (and probably
> READ-BYTE) -- you can find the messages on the list from around June
> 21-25. My findings with Shark were similar to yours. When you look at
> Shark's hierarchical view (don't remember what it is called) a lot of
> the activity is underneath READ, where I saw the locking going on. In
> my case it was some very high figure like 60% of activity associated
> with READ.
> I figured it had something to do with making streams work with
> multiple thread access, but didn't really pursue it further (rather
> bookmarking it for future exploration, but I've got so much
> bookmarked material that I'm really glad you encountered the same
> issue and brought it up!)
The same here. I have lots of messages bookmarked (especially
Gary's). CHUD/Shark stuff was one of them.
> It is possible that I'll run up against this same issue with reading
> and writing network connections -- I haven't Sharked this yet.
I think it is likely.
> I suppose it is possible that there are some more hackish methods,
> like building non-locking (and non-CL) read/write primitives that can
> at least work with unix file descriptors and bytes (which is all I
I experimented a bit:
;; call tyi without lock
(ccl::%ioblock-tyi (ccl::stream-ioblock stream)))
(defun foo (file no-lock)
(with-open-file (in file)
(change-class in 'file-character-input-stream-no-lock))
(loop for char = (read-char in nil nil)
(foo "/Users/keke/a-file" t) is about twice as faster than
(foo "/Users/keke/a-file" nil).
> BTW It may not be fair to compare Openmcl and Allegro CL in READ
> performance, since Allegro is not native-threads on OS X.
I agree. MCL 5.1 does not use native (preemptive) threads either.
More information about the Openmcl-devel