[Openmcl-devel] slow read-char

[Takehiko Abe]

Hi, Erik

> 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  
> need)??

I experimented a bit:

(in-package :cl-user)

(defclass file-character-input-stream-no-lock
    (ccl::file-character-input-stream)
  ())

;; call tyi without lock
(defmethod stream-read-char
    ((stream file-character-input-stream-no-lock))
  (ccl::%ioblock-tyi (ccl::stream-ioblock stream)))

(defun foo (file no-lock)
  (with-open-file (in file)
    (when no-lock
      (change-class in 'file-character-input-stream-no-lock))
    (loop for char = (read-char in nil nil)
          do
          (unless char
            (return)))))

(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. 

regards,
T.