reading a file into a string on ACL

Martin Elster <[email protected]>
Newsgroups gmane.lisp.allegro
Message-ID <[email protected]>
Greetings, 

When I try to read a file into an array using ACL it is painfully
slow. The function I use is this:

(defun file->string (file-name)
  "Reads file <file-name> returning a string of its contents."
  (proclaim '(optimize (speed 3) (safety 0)))
  (let ((result (make-array 0 :adjustable t :fill-pointer 0)))
    (with-open-file (stream file-name :direction :input)
      (do ((char (read-char stream nil nil)
                 (read-char stream nil nil)))
          ((null char))
        (vector-push-extend char result)))
    (coerce result 'string)))

When I run the function on a file of 442K it takes close to 40 minutes
to run. 

cl-user(33): (let ((*print-pretty* nil)) 
  (time (progn (file->string "tmp1.txt") (values))))
8727128 bytes have been tenured, next gc will be global.
See the documentation for variable *global-gc-behavior* for more
information.
; cpu time (non-gc) 1,767,970 msec (00:29:27.970) user, 2,240 msec
system
; cpu time (gc)     162,860 msec (00:02:42.860) user, 440 msec system
; cpu time (total)  1,930,830 msec (00:32:10.830) user, 2,680 msec
system
; real time  2,268,903 msec (00:37:48.903)
; space allocation:
;  135,774 cons cells, -1,008,972,256 other bytes, 0 static bytes
cl-user(34):

When I run it on CMUCL, it takes about 0.2 seconds.  

USER> (let ((*print-pretty* nil)) (time (progn (file->string "tmp1.txt")
(values))))
; Compiling LAMBDA NIL: 
; Compiling Top-Level Form: 

; Evaluation took:
;   0.23 seconds of real time
;   0.2 seconds of user run time
;   0.0 seconds of system run time
;   461,131,944 CPU cycles
;   1 page fault and
;   4,653,584 bytes consed.
; 
USER> 

So this trial takes about 10 000 times as long on CMUCL as on ACL. 

I'm using ACL 6.2 on Redhat 9 x86. Does anyone have any idea what is
going on here? Could it be a bug? Or am I missing something here? 

Thanks,

martin
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.