Hi Jean, I'm using qxbuild and the deploy time of my application (when I do changes in server or client code) is one or two seconds. Personally I don't like the qooxdoo generator and the need to use specific file structure for scripts. I'm using just qooxdoo and my library/application scripts without touching generator for deployment. Qxbuild contains one nice feature which allows dynamically choose debug/release version of qooxdoo so I can debug some script files also in deployed environment.
Just my two cents. Best regards Petr Kobalicek On Tue, Aug 17, 2010 at 2:45 PM, Jean-Baptiste BRIAUD -- Novlog < [email protected]> wrote: > Hi Petr, > > On 17 août 2010, at 14:36, Petr Kobalíček wrote: > > Hi, > > I think that only way that could improve the speed is using multiple cpu > cores (in python threads are not solution because of GIL) or rewriting > generator in language that allows better optimizations (C++, Java, etc...). > Python is slow, interpreted language and it's not good for performance > critical things. > > Another solution could be using precompiled qooxdoo and compiling your own > filed by using yuicompressor. I think it's quite good, many frameworks are > using it for javascript compression. > > > Could you go please develop further that precompiled qooxdoo version, I'm > not sure to understand ... > If we do that, I won't use any compressor like yui one. I don't care of > optimization for that use case. > I only want to run as quickly as possible a qooxdoo application in the same > way generate build package it, > using generate source is different because it doesn't embed SDK, and > qooxdoopath is a problem under a web server. > > If I want to deliver the application, for example to production or other > than local developer machine, I'l use generator and classical qooxdoo > compile. > > > Best regards > Petr Kobalicek > > On Tue, Aug 17, 2010 at 2:10 PM, Jean-Baptiste BRIAUD -- Novlog < > [email protected]> wrote: > >> Nothing to do fpr the CPU, fair enough. >> >> Any other things to try on Python side (memory, ...) ? >> >> Any other "trick" like cache on a ram disk ? >> >> Any other ideas like "helping" the generator by some way ? >> >> What about tweaking SDK by removing some unused things (component, ..) ? >> Will that help to speed up the process ? >> >> Last already known idea : qooxdoo in one big js non optimized file ... >> In such a case, we would use that one big file for our frequent dailly >> build/run/debug but will keep using generate build for delivery version >> since generator do lots of wanted optimization. >> As already discussed, I know it should be doable to create that big file >> from the SDK, but I'm not sure how to start with since I'm not fluent in >> config.json :-) >> >> thanks ! >> >> On 17 août 2010, at 13:32, Martin Wittemann wrote: >> >> > Hi, >> > >> >>> Yes, I was thinking that way before noticing that during a generate, >> the CPU is not 100%. >> >>> Would it be possible that my Python implementation doesn't use all >> available CPU ? >> >>> I'm on Mac and I didn't install anything, just using default Python >> installation. >> >>> >> >>> Is there any Python option that I can use to reduce time for a >> generate build ? >> >>> For example, allowing more memory ? Would it make sense, is it >> possible in Python ? >> >>> Other idea ? >> >>> >> >> The generator only uses a single CPU core. During a build, that core is >> >> definately at 100% on my system (using the default Python install that >> >> comes with Ubuntu). >> > >> > I'm not the python expert either but I know that the generator uses only >> one core for sure. We already have a bug report to change that: >> > http://bugzilla.qooxdoo.org/show_bug.cgi?id=2366 >> > >> > But as far as I can remember, thats not as easy in python. (correct me >> if i'm wrong). So there is nothing you can do right out of the box to split >> up the generator to run on multiple cores. >> > >> > Regards, >> > Martin >> > >> ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by >> > >> > Make an app they can't live without >> > Enter the BlackBerry Developer Challenge >> > http://p.sf.net/sfu/RIM-dev2dev >> > _______________________________________________ >> > qooxdoo-devel mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev_______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > >
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
