scsh-hackers
[Top] [All Lists]

[Scsh-hackers] [ scsh-Bugs-407793 ] external symbol lookups

To: noreply@sourceforge.net
Subject: [Scsh-hackers] [ scsh-Bugs-407793 ] external symbol lookups
From: nobody <nobody@sourceforge.net>
Date: Sun, 11 Mar 2001 18:13:05 -0800
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Sender: scsh-hackers-admin@lists.sourceforge.net
Bugs #407793, was updated on 2001-03-11 18:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110493&aid=407793&group_id=10493

Category: run-time
Group: None
Status: Open
Priority: 5
Submitted By: Brian D. Carlstrom
Assigned to: Olin Shivers
Summary: external symbol lookups

Initial Comment:
From: "Robert E. Brown" <brown@grettir.bibliotech.com>
To: bdc@ai.mit.edu
Subject: external symbol lookups
Date: Tue, 5 Nov 96 00:52:43 -0500


OK, I took a peek at the Scheme code involved in 
external symbol lookups.
The first thing I noticed is that lookup-all-externals 
eventually calls
find-all-xs, which walks the pure and impure heap 
areas looking for "external"
objects.  This must be expensive!  Once all the 
external objects are found,
their addresses are computed and added to a table.

Luckily, the get-external lookup function is smart 
enough to call
the external lookup function if the external it is 
searching for is not
immediately found in the table.  This means that the 
table really does not
have to be filled with data when scsh resumes -- it 
will be filled lazily
by calls to get-external.

Please try the following patch to startup.scm.  It 
turns off the immediate
filling of the external table.


demeter [73]  diff -c startup.scm.~1~  startup.scm
*** startup.scm.~1~     Thu Oct 31 15:18:06 1996
--- startup.scm Tue Nov  5 00:38:31 1996
***************
*** 51,57 ****
  (define (scsh-stand-alone-resumer start)
    (usual-resumer  ;sets up exceptions, interrupts, 
and current input & output
     (lambda (args)     ; VM gives us our args, but 
not our program.
!      (init-scsh-hindbrain #t) ; Whatever. Relink & 
install scsh's I/O system.
       (call-with-current-continuation
         (lambda (halt)
         (set! %vm-prog-args (cons "scsh" 
args))        ; WRONG -- use image.
--- 51,57 ----
  (define (scsh-stand-alone-resumer start)
    (usual-resumer  ;sets up exceptions, interrupts, 
and current input & output
     (lambda (args)     ; VM gives us our args, but 
not our program.
!      (init-scsh-hindbrain #f) ; Whatever. Relink & 
install scsh's I/O system.
       (call-with-current-continuation
         (lambda (halt)
         (set! %vm-prog-args (cons "scsh" 
args))        ; WRONG -- use image.

With this patch, scsh on my machine now starts up in 5 
seconds instead of 8.
A resumed "ekko" heap created with dump-scsh-program 
now runs instantaneously.
It used to take 7 or 8 seconds to run.

I believe that most of the 5 seconds that scsh now 
takes to start up are
related to reading the heap.  I have not tried 
static.scm with the above
patch.  If I get a chance, I'll profile the heap 
reading and other startup
actions to see if I can pare a little more time away.

By the way, Olin had posted a note to 
comp.lang.scheme.scsh indicating that
he could start up scsh in 0.1 or 0.2 seconds on some 
box.  I am still curious
how he was able to achieve this!

                                bob



----------------------------------------------------------------------

Comment By: Brian D. Carlstrom
Date: 2001-03-11 18:13

Message:
Logged In: YES 
user_id=27364

From: "Robert E. Brown" <brown@grettir.bibliotech.com>
To: bdc@ai.mit.edu
Subject: startup times
Date: Tue, 5 Nov 96 02:10:31 -0500


To complete the story, I just generated a scsh.vm using the 
official
scsh.image file.  This static scsh starts instantaneously 
the second
time it is run -- it takes a few seconds the first time.  
The standard
/usr/local/lib/scsh/scshvm version always seems to take 3 
seconds to
start, but that may be related to the fact that my heap 
image is on
an NFS file server.

                                bob






----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110493&aid=407793&group_id=10493


<Prev in Thread] Current Thread [Next in Thread>