Hello Thomas,

Wednesday, March 24, 2004, 6:54:31 PM, you wrote:



>> Have you tried the same under Linux ?
>> Maybe this can give us a clue what is wrong.

TS> I have now:

TS>  18:47:02  up 33 days, 23:19,  2 users,  load average: 1.38, 0.97, 0.43
TS> 58 processes: 57 sleeping, 1 running, 0 zombie, 0 stopped
TS> CPU states:  11.3% user   4.7% system   0.0% nice   0.0% iowait  83.8% idle
TS> Mem:   223140k av,  220044k used,    3096k free,       0k shrd,     752k
TS> buff
TS>                     141028k actv,   29580k in_d,    3632k in_c
TS> Swap:  457844k av,  231440k used,  226404k free               4788k
TS> cached

TS>   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
TS> 26968 ts        15   0  272M 160M   500 D    11.1 73.6   1:16 0 ruby
TS> 26966 ts        15   0  4116 1052   500 S     0.0  0.4   0:03 0 emacs
TS> 27036 ts        15   0   976  840   684 R     0.5  0.3   0:00 0 top

TS> I grew tired of waiting on it (my linux box only has 256 megs of memory)
TS> when it had about 780 temporary files at which point the process was using
TS> 272MB of memory.

TS> So it is pretty much the same on linux - not surprisingly.

TS> I have made a few other experiments, including implementing my own TempFile2
TS> class. If I use the same strategy as Tempfile and use a SimpleDelegator to
TS> delegate to an instance of File I get the same memory consumption. I haven't
TS> figured out why it is so..

I also had a quick look at TempFile and couldn't find something in the
data modell that would justify this memory overhead. So i guess you
are right it has something to do with the code model und the internal
representation of the parse tree. Have you looked at the object space
which objects are available at the end of the run ?



-- 
Best regards,
 Lothar                            mailto:mailinglists / scriptolutions.com