New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
speed mako up a lot #76
Comments
Michael Bayer (@zzzeek) wrote: the patchfile has the same issue as the patch in #78:
not sure why that is since the #77 patch works. Anyway, I'm concerned about nailing "buffer_stack[-1]" into the local namespace since its not apparent to me yet if that value changes at all (also its kind of ugly). so see if you can get me a patchfile that works at least and i can play with it. |
Anonymous wrote: new patch file, please review again. |
Michael Bayer (@zzzeek) wrote: thanks. as I expected, because you're nailing to a specific buffer in the context, several unit tests fail:
|
Anonymous wrote: new patch was added, all the test passed except test_basic (call.SelfCacheTest), which is too magic and should not been recommanded to use. |
Michael Bayer (@zzzeek) wrote: I would greatly prefer that this patch not dig into context like that. While we aim to be fast, when it starts becoming that the internals are being disassembled within compiled templates its getting out of hand. Theres also a try/except block in it - exception catches are very expensive. And any template that defines a variable or function named "write" will fail. It seems like a lot of complexity for a microscopic speed improvement. From my point of view, mako is already running on http://reddit.com and we're plenty fast - bigger speed improvements would probably come from native extensions if anything. There are some speed issues involving the "import='*'" flag in <%namespace> but core Mako performance is excellent (the removal of the unicode() method is more compelling). How much does this patch actually speed things up ? Do you have any time-oriented profiling data ? |
Anonymous wrote: I take a real page to profile: http://www.douban.com/ before applying this patch:
after applying this patch:
As we see, it speed up about 15% in whole page rending time (31ms to 26ms). by excluding the data collecting time (outside Mako, about 15ms), it speed up about 30% (16ms to 11ms). If the page is more complex, it speed up more. If making using FastEncodingBuffer or cStringIO sure, the "try ... except ..." is not neccessay. btw, it seems that filter "html_escape" also need some optimization. |
Anonymous wrote: It is clear that Mako is pretty fast, and faster than other Python Template, such as Genshi, but is slower than PTL(Python Template Language), used in Quixote. PTL is not a complete template, but it is super fast. Recently we want to replace PTL as Mako, so want to make Mako as fast as PTL. |
Michael Bayer (@zzzeek) wrote: OK, can you try the attached patch please ? Same idea, but we leave the |
Changes by Michael Bayer (@zzzeek):
|
Migrated issue, originally created by Anonymous
there are too many context.write() in compiled module, it stands for context._buffer_stack[-1].data.append or context._buffer_stack[-1].write, causes a lot of overhead.
make a shortcut for i can reduce the overhead and speed up mako a lot.
Attachments: speedup_2.patch | speedup.patch
The text was updated successfully, but these errors were encountered: