Changes between Version 17 and Version 18 of DeveloperGuidelines/Optimisation


Ignore:
Timestamp:
04/20/10 12:17:51 (15 years ago)
Author:
Fran Boon
Comment:

Copy information Dominic provided on Mailing List

Legend:

Unmodified
Added
Removed
Modified
  • DeveloperGuidelines/Optimisation

    v17 v18  
    1010 * http://diveintopython.org/performance_tuning/index.html
    1111 * If a specific inner-loop routine canot be optimised in Python, then consider writing a C routine for this use case.
     12
     13 1. Optimize the models, throw away what we don't need. Every field counts.[[BR]]Especially problematic in view of performance are references (joins), as they execute implicit DB requests. The more complex references are, the slower the model loads.
     14
     15 2. Function definitions in models do _NOT_ harm - the functions are not executed when the model is loaded, but just compiled - pre-compilation of the whole application gives a speed-up of just 10ms (compare to the total execution times!).[[BR]]In contrast to that, module-level commands (which are executed at time of loading of the model, e.g. CRUD string definitions) slow it down. Suggestion: put them into a "config" function for that model, and call only as needed.
     16
     17 3. Everything that is static should be in the "static" folder - that applies especially to static !JavaScript. If you put such in views, it gets processed by the view compiler and passed as dynamic content, which is totally unnecessary. Loading from static also gives the advantage that it gets cached by the webserver _and_ the client.
     18
     19 4. Avoid _implicit_ redirects! (that is, without user
     20interaction, e.g. as in open_module. There may be redirects that cannot be
     21avoided.).[[BR]]A redirect simply doubles the response time (executes a new request and thus loads it all again).
     22
     23 5. Be careful with Ajax - this might work nicely in local environments, but in real-world deployments this has shown to be unreliable and slow.
     24
     25 6. Python runs very fast as opposed to DB queries, so it can be much faster to retrieve 100 rows in one query and then drop 95 of them in the Python code, than to retrieve 5 rows in 5 queries (=do not loop over queries, better loop over the results).
     26
     27NB Performance is not everything, and you should not optimize any code without actually having a problem with it. In most cases, response times of
     28around 600ms are totally acceptable (or a minor compared with the average download times on-site).
     29
     30There are more things to consider besides performance, e.g. usability and maintainability of code. New contributors should be able to easily understand the code, and bugs should be easy to find.
    1231
    1332=== Specific Examples ===
     
    4059 * http://mg.pov.lt/profilehooks/
    4160 * YSlow plugin for Firebug: http://developer.yahoo.com/yslow/
     61 *  You can also use [http://www.pylot.org Pylot] to test the application's behavior under load, and get more reliable results (+ in a nicer report form).
    4262
    4363----