On May 25, 12:28 pm, Jorge Vargas <[email protected]> wrote: > > I'm not sure why all of > > PIL, > > to serve generated images
What generated images exactly? Most applications don't dynamically generate images (and if they do, they may be using something different than PIL). > > genshi, > > the default But not necessarily the default for the developer's application. > > mako, > > because it's used by some components (WebError I believe uses it by default) Uh. What if WebError isn't used (i.e. in non-debug mode)? > > tempita, > > For paster templates to work, not entirely sure why it's loaded at runtime Which is kind of the point I'm trying to make... > > pygments (!), the > > weberror Again (see above). > > tw.core subhierarchies, > > because you use widgets (for example the admin) What if I don't use the admin, and build my own forms? It's a bit puzzling: turbogears claims it's about choosing your own third-party modules for each functionality (templating, forms, etc.), but it loads all of the alternatives at startup. It also means that, as things progress and TurboGears gets more and more functionality, it will also load more and more modules even when people don't need them. > > among others, have to be > > xml.* is used by genshi Yes... see above. > by the way in the tg2.1 branch most of the peak.* stuff is gone. Good news :-) > And again I use django as an example, you will load to memory all the > equivalents of the above plus the admin, plus the geospatial library > code, plus whatever else the decide to put into their monolitic > package. Ok, but I'm not that interested in Django. That's why I'm posting here after all (not on the Django ML). > it will never garbage collect these > modules, they are "persistent" memory, You are mistaken about how the cyclic garbage collector works. The GC has to scan all objects (all GC-enabled ones) before it can /know/ what can be disposed of and what must be kept alive. See also my timing example, which should be eloquent enough as to the overhead of unused modules. > the only part of your memory > that will change is that of the request and the thread-local objects. Actually, the GC itself will update some hidden fields in the objects it traverses, in order to keep track of what must be kept and what can be discarded. See gcmodule.c in the Python source tree for details :) Regards Antoine. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
