I can answer of couple of these: On Mon, Feb 9, 2009 at 9:29 AM, Mike Wesner <[email protected]> wrote:
> 1. How does the import cache work exactly? I have read docs but still > am left with questions on how exactly it works. If we have a main.py > with our main() method in it... are all the imports in that file > cached? Is there a way to keep our custom django in memory? > All imports are cached on a per app server basis. The first time the app imports a module on an app server, the module is loaded from disk and evaluated. Subsequent imports of that module on that app server do not load or evaluate any code, in the same sense as if you imported a module more than once in a single run of a Python application. If a handler script (a Python code file associated with a URL mapping in app.yaml) has a main() method, the entire script is loaded and evaluated the first time the URL is requested. On subsequent requests for the URL, the main() method is called without re-loading or re-evaluating the script. This is similar to "importing" the handler script, with the minor difference that the main() method is not called directly on the first request, so you still have to call it in the script's code (see docs for examples) for the first request to succeed. If a handler script does not have a main() method, it is evaluated in full for every request, and its global variables are not retained on the app server between requests. > 2. Since so many people use custom django, is there any plan to > provide other versions of django besides the .96 version? Would it > be possibe to provide .97 and 1.0 under some other name (import > django97 as django)? I have read that the provided django is always > loaded in memory and thus would be faster. It would sure save us a > lot of files to upload also. So far we're mostly considering upgrading the bundled Django only for the next major API version. With the way the module load path works today, it'd be difficult to introduce new modules into the default environment as a backwards compatible change. As I've gone on about before here in the group, having major third-party packages bundled with the API is not a good way to go in the long run, and I'd rather see this need addressed by making third-party packages easier to add to apps. App caching ought to be sufficient for mitigating the time spent importing modules. Have you profiled your imports to see if they're a major contributor to performance issues? Lazy importing (putting the import statements directly in the code paths, instead of on module start-up) can help reduce the cost of that first per-server request, though that's not always easy to do when using a framework. -- Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" 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/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
