[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: es memory requirements
Date: Tue, 5 Jan 1993 18:25:19 -0500
From: Paul Haahr <haahr@mv.us.adobe.com>
Subject: Re: es memory requirements
|> When would you expect "the next time a collection is done" to happen? I'm
|> thinking perhaps, if I could induce a collection at certain points, things
|> might improve.
|
| that's pretty easy. we'll probably introduce a $&collect primitive which
| calls the collector and returns. (if you want to hand carve one, just call
| the function gc() from the primitive and return true. that should be
| sufficient.)
OK, that was easy. Results weren't exactly what I expected, though -
;; ps -Fp $pid
UID PID PPID C SZ RSS ENG STIME TTY TIME COMMAND
root 24449 17947 0 296 156 16:01:22 ttyAF/ADFE 0:00 ./es
;; collect
;; ps -Fp $pid
UID PID PPID C SZ RSS ENG STIME TTY TIME COMMAND
root 24449 17947 6 368 208 16:01:22 ttyAF/ADFE 0:00 ./es
;; collect
;; ps -Fp $pid
UID PID PPID C SZ RSS ENG STIME TTY TIME COMMAND
root 24449 17947 10 512 280 16:01:22 ttyAF/ADFE 0:00 ./es
;; collect
;; ps -Fp $pid
UID PID PPID C SZ RSS ENG STIME TTY TIME COMMAND
root 24449 17947 13 512 280 16:01:22 ttyAF/ADFE 0:00 ./es
In short, the first two "collects" increase SZ (total size) and RSS (resident
set size), after which there's no effect. That was after allocating a few
functions and lists - not a very systematic test, and with the starting
point (156/296) at the relatively modest size we see when we start the program
up, so I can't say for sure what it would do to my application - but I'm not
sure it's worth bothering with.
Incidentally, we did some tuning this morning, and while it helped streamline
virtual memory use overall, es was reportedly immune to the tuning. That is,
of that memory it allocates, we were unable to get any to page out. Probably
not surprising - it seems obvious that an interpreter like this, without
any particularly specialized faculties, would tend to always be doing all
of the things it does, and not ignoring any large region of its address
space.
Donn Cave, University Computing Services, University of Washington
donn@cac.washington.edu