On Sat, Jan 28, 2012 at 12:21 PM, Jeffrey Van Voorst <[email protected]> wrote: > > What happened to slow it down? Support of more browsers? or a lot more > items get put in the js files to support more of the python language? > Note I am assuming it is the download time, but I suppose it could > also be initializing the javascript on the page itself. Is there much > that could be done without breaking the "compatibility" between GWT > and pyjamas? In other words, if radical changes are made, one might > not be able to convert the Java GWT code to Python as easily as is > currently done.
the modules we actually split into a gwt namespace in the belief it would be easier to stay in sync with upstream in the future. pyjamas modules then import and extend/from these classes. this means more files in --multi-file mode, or bigger download in single file mode. tbh i don't notice it all that much ... the server uses gzip encoding and a ~1.4MiB cache file become ~250KiB on the wire (the mail app). > If it is the download time, one can do things like remove all white > space from the js files on their production webservers, etc. On the > other hand, if it is really true that current versions of chrome and > firefox have much faster javascript engines than a year or two ago, I > would have expected a decent jump (with respect to the same version) > in pyjamas loading performance. yes minification is a good way to achieve less, but ultimately caching is the silver bullet. take the mail app for example, once loaded once, the cache file returns a 304 Unmodified and the page loads near instantly for me. the problem is many people do not use --multi-file builds, and this means *every* single time you change *anything*, you force users to download the full cache file *again*. --multi-file prevents this by only invalidating the cache of the module you actually modified. you can take this a step further, and put the modules on a common domain ... then *all* of your apps get free cache hits, cross-domain. of of my goals is to setup an on-demand build + minify service proxied thru Coral Cache, then you can pull modules from, say: http://modules.pyjs.org.nyud.net/{module-hash}/ (with fallback to your server) ... and if we *all* use this service, then we get free caching if a user visits more than one pyjs-based site (and the sites are using the same module versions). i guess i think most of the perceived perf issues are due to deployment, not the engine itself, but there are certainly areas that could be improved (for example, eliminated the HTTP gets of virtually empty __init__.py files, among others) -- C Anthony
