Hi Jean, I think that very efficient way to improve compiler is to write it in C++ :-) It's python and I think that speed was no primary goal when started writing it (Python language and Generator itself). There are extensions to python that tries to jit compile some parts (don't know their names, maybe psyco and one from google), but it's still not so good.
And about qxbuild, why is your application taking too much time to load? (compared to build version) Are you distributing it as source or it's minified? If you are using Java there is pretty good YUICompressor that can minify your code a lot. It means work, but I can imagine tool that will read #assets (to get dependencies) and that will use YUICompressor to distribute all your files as one bigger one instead of qooxdoo generator. Currently I'm not using this way, but I think it's possible and in Java world it's probably much better solution than using Python. Or using qxbuild together with qooxdoo generator that will generate only your files (qooxdoo will be precompiled). This seems like good idea for me too. I think that there is minimal size difference when using qxbuild with larger application. You are using many widgets and saving 200kB to 300kB in JS code is nothing. And last thing, qooxdoo is LGPLed, so you should have your minified code in different file than qooxdoo is - lawyers, is this correct? (This is also reason I'm using MIT style licenses, because I'm not lawyer:) ) Cheers - Petr 2009/9/29 Jean-Baptiste BRIAUD -- Novlog <[email protected]>: > Hi Thomas, > > On Sep 28, 2009, at 23:39 , thron7 wrote: > >>> I did some chrono and got 3 minutes !!! >>> It's just too long for a very simple application (15 classes, all >>> included) without translation, without ressources. >> >> Standard "Playground" application, 2 (!) app classes (but 240 classes >> including dependencies), on a single-core Windows machine with native >> Python installation, and empty cache: >> >> 0.03user 0.04system 18:41.71elapsed >> > What do you mean by *native* Python installation ? I'm thinking there > might be some room for improvement on my side by ensuring I'm using > native implem. Currently, I'm just using default MacOS Python install > on dev environment and the one provided by apt-get on production > (Ubuntu) environment but I never checked if it is native or not. What > should I do to esure that it is native ? > > I'd like to try all I can on my side for the compiler to make it > quicker : > > 1. Could the use of #require and #use speed up the compiler ? The idea > would be for us to write some dependencies explicityly to help the > compiler. > > 2. Going futher, does it make sense to disable automatic dependencies > finder in the compiler ? > Let's explore that hypothesis. > Once disabled, we'll have to provide *all* dependencies using #require > and #use (like import in Java) and so the compiler will not have to > parse all the classes and thus will not have to walk the AST on each > file. I guess javac is quicker because it doesn't provide the same > level of service as qooxdoo compiler. It provide less by not deducting > the load dependency at all (still has to check for run-time dep if I > understood correctly). The developper has to provide all needed import. > could that speed up the compiler ? If yes, It could be an optional > compiler directive. As we are generating all the qooxdoo code, it > won't be a big deal to add all the required #hints. > > 3. One other solution I can imagine would be to introduce 2 states for > our produced application. The "quick" one that would use the qxbuild > from Petr (or other if any). A bit long to load (5 seconees) but very > quick to produce (2 secondes). And the "production" one that would use > the official build for a very quick to load (instant or 1 second) > application but very very long to produce (Few minutes. Probably > nearly 5 for most of the applictions) but the end-user will know > exactly what he will have because it would had been able to test it > very quickly with the "quick" version. Generate.py source doesn't fit > the need for the "quick" version as it is too long to load (10-20 > seconds) and too heavy and complex to deploy with the SDK. > > By the way, this is the occasion for me to ask the question : what do > we do about qxbuild and official build ? > @Petr : did you push the qxbuild in the contrib SVN ? If no, why, is > there something that could be done to help doing it ? > @qooxdoo team : are you OK to include officially the qxbuild or an > equivalent of your choice, there is various need for a qooxdoo all-in- > one file. > > >>> The chrono goes down to 20s for a second compile without any change >>> in >>> the code of the application. >>> >>> I'm wondering if some task could be run parralel in the generator ? I >>> noticed that only one core is used (both cores at 50% on my core 2 >>> duo). >> >> No, currently no concurrent version of the generator, and Python's >> global >> interpreter lock complicates things further. (See "Multi-threaded >> Generator" here: http://news.qooxdoo.org/the-week-in-qooxdoo-2009-04-17) >> . > OK, I understand. >> >>> >>> Where are the cache store ? >> >> If you are using default settings, it depends on your system, see >> the docs >> (e.g. >> http://qooxdoo.org/documentation/0.8/snippets#finding_your_system-wide_tmp_directory) >> > That's where it goes for me ! > /var/folders/0z/0zYQqHU8Gay4EvakgLs4uk+++TI/-Tmp- > Inside this folder, there is a cache sub-folder, as defined in the > config.json ("CACHE" : "${TMPDIR}/cache"). > > Can I safely change the CACHE settings in the config?json to anywhere > I want ? > > >>> I'm thinking to "cut and paste" cache folder for a given application >>> so I could have a hot compile (cold one would be the very first one) >>> ensuring that the system or our own code didn't wipe cache out >>> between >>> compile. >> >> Yes, keeping the cache around would be a good strategy for you. I >> presume >> the app code you are generating is different between invocations, so >> that >> needs to be generated afresh. But you can keep all the framework >> classes >> (and other lib/contrib classes you are using) in the cache, and they >> will >> be re-used with every generator run. That will give you a significant >> speedup. >> > The content of that cache folder is files like > tree-0d0fdf07a0c1c13f7b4ead0f9aca0354072a9450 > and > compiled-ffb4659c2687117db4a36ed3c73dfaaf88116cb8 > > So, there is no obvious way to link files and a given application. > How could I "produce" a cache containing the framework and all my libs > but without app so I could fake a hot compile while it will be a cold > one ? > > Other ideas welcome :-) > > Thanks. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
