4 ms·
You could do the import and then fork the child processes. That should share all the memory used by the nitk module between all the children (for as long as the
by lobster_johnson 16y ago
You could do the import and then fork the child processes. That should share all the memory used by the nitk module between all the children (for as long as the memory is not modified by anyone, which triggers a copy-on-write allocation of the affected pages).
- baq 16y agomost forks do copy-on-write and every access to a python object meddles with reference count, which is - you guessed it - a write.
- froydnj 16y agoThe context of the copy-on-write win was the bytecode for modules. I don't know that you'd have anybody meddling with the reference counts for that...but I haven't really looked.
- rayiner 16y agoBytecode is stored in function objects which IIRC are reference-counted.
- lobster_johnson 16y agoAside from ad-hoc classes (defined within the scope of a function, say), does it ever make sense to garbage-collect a module or a class? Say you do "import smtplib" in your main file. Now that module is imported -- forever. I don't know the internals of Python well enough, but I bet that the module reference has strong references to its contents, so that even if nobody is actually calling anything in smtplib, it will be there in case someone does. The same should be true about modules importing other modules; they stay visible at the scope-level, so they are permanently loaded. So for those cases it would make sense to keep them separate from global garbage collection. I'm pretty sure that the method tables of all the classes in the system take up considerable space, probably in the order of megabytes for many apps.