Re: [Distutils] formencode as .egg in Debian ??
Bob Tanner wrote:
When I read the above, my knee-jerk reaction is: Where is the data to backup
this statement?
One could show strace outputs, and compare the number of system calls.
Compiling this into actual timing is difficult: you would have to trade
stat calls for read calls, and you would have to take the operating
system's disk and directory caching into account.
How much slower?
Not noticably, for a small number of zip files, and non-trivial
Python scripts. Likewise, the presumed speed advantage of zip files
(for zip file directory hits) is just as unnoticable, due to OS
caching (depending on the OS, of course, and sizes of directories).
We talking milliseconds, seconds, minutes? Yes, there are
variables, here, but narrow them to a set number and compare zip vs
directory?
Milliseconds, either way.
Previous post talked about memory consumption, again bytes, kilobytes,
megabytes?
This is easier to say. For FormEncode-0.4, which contains 51 files,
the Zip directory is 3625 bytes. Now, this is stored in memory somehow:
Each file ends up as a directory entry, e.g.
'formencode/fields.pyc':
('/tmp/FormEncode-0.4-py2.4.egg/formencode/fields.pyc', 8, 12603, 34753,
69084, -28392, 13172, -784586915)
This makes 12 pointers (48 bytes) for pointers in containers per file
(3 in the dictionary, 9 in the tuple), plus 7*12 byte for the integers
(some shared, of course), plus 3*12 bytes for the string and tuple
headers, plus the characters for the strings (including null bytes,
4146 bytes for FormEncode). Counting this all together, the
in-memory usage is about 4300 bytes for FormEncode; if I had
this in /usr/lib/python2.3/site-packages instead of /tmp, it
would be larger.
This is roughly 2% of the egg file size. Larger eggs likely
have more files, so this might serve as an estimate. The memory
overhead would occur for all eggs installed, for all Python
scripts.
Regards,
Martin
Reply to: