Re: PURESIZE increased (again)

[Eli Zaretskii]

> Cc: address@hidden
> From: Ken Raeburn <address@hidden>
> Date: Fri, 28 Apr 2006 03:07:35 -0400
> 
> > That's the point: how _could_ they be different?
> 
> Barring the obvious, like local hacks affecting the byte-code  
> optimizer, or some local bug causing character encoding conversions  
> to be applied to byte-code strings, I have no idea.  But since I have  
> no other good idea how the 20K difference came up loading a .elc  
> file, I figure breaking the problem down might help.  For example:  
> First, confirm that some file foo.elc to be loaded is (functionally)  
> the same, and that it consume different amounts of storage, on the  
> two systems.

Yes, if we find no other explanation, comparing .elc files would be
the way to go.

> Then split it apart (binary search, one S-expression at  
> a time, whatever) and see if there's some particular kind of  
> expression in the .elc file that consumes different amounts of  
> storage on the two systems.

No need for binary search, I think: since we are debugging pure
storage use, it's better to put a breakpoint on the functions that
allocate space off pure[], and then xbacktrace will show what
expression is being evaluated, while the C code will show how much
pure space is being allocated.

> If people want to expend that much effort on it, of course.

275KB of memory sounds like a good reason to me, but that's me.