On Monday 25 May 2009 12:46:28 Antoine Pitrou wrote: > On May 25, 12:12 pm, "Diez B. Roggisch" <[email protected]> wrote: > > Then there is the question who's going to decide when it's ok to import > > what - via configuration? > > Why do you need configuration at all? TurboGears should /know/ when > and why it needs a given package, shouldn't it? > As for my code, if I have to use tw, I just "import > tw.whatever_package". > If I have to use pygments, I just "import pygments".
Because things don't work as simple as that. There are e.g. entry-points enumerated which will trigger module importing even without an explicit import-statement. Also, lazyfying makes code much more complicated, will lead to hard to debug errors and so forth. > > > Loading lots of modules has a real cost. Besides inflating memory > > > requirements (and potentially decreasing CPU caches/TLBs efficiency), > > > > Please, we are talking about python here, not hand-optimized LAPACK code. > > Why do you think CPU caches are only useful for LAPACK code? > A Python program (code *and* data) is a big number of PyObjects > referencing each other. The interpreter is continuously chasing > pointers. When such an object is not in the CPU cache, you will suffer > the access latency of main memory. But only for those *running*. > > And > > resident modules loaded but not actively used do degrade CPU caches in > > exact what way? > > For example, garbage collection periodically walks the list of all GC- > enabled objects. Which is quite a lot of them. And it's probably very > cache-unfriendly. Actually, I've given the numbers in a previous > message. > (loading a module creates dicts, tuples, and all kinds of other GC- > enabled structures. Even functions are GC-enabled objects) I don't know about GC in python much, but AFAIK reference-counting is there so that you do *not* require permanent object graph traversal. http://effbot.org/librarybook/gc.htm seems to support this view. > > All of this without a compelling usecase for optimizing - sorry, but you > > won't get far with this anywhere unless you show a real impact for a real > > use-case - not some premature optimization guesswork. > > A compelling use-case? Well, any Web application with some kind of > popularity would be a compelling use-case. Your objection is like > answering "there's no compelling usecase for optimizing" to someone > complaining that tg does 10 superfluous SQL requests for each page > request (I'm not saying it does that, it's just a hypothetical > situation). In the same sense every application would be compelling use-case for writing major parts of TG in C++. You seem to think the imports are just there for the fun of it, and getting rid of them is trivial and it's just a matter of laziness that it isn't done. It is not. It's a lot of work, with debatable outcome - and this debate is entirely moot unless someone (you, or whoever cares) shows that doing this or that reduced the response-times of his or her app remarkably, or any such thing. We are talking optimization here - *never* a subject to tackle without real data. Diez --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
