Am 28.02.2008 um 17:25 schrieb Leander Hanwald: > Tank you for the reply Sebastian.
Hi Leander, > > > It's clear that we talk only about the init transfer time (network > transport), but it's an important part of the feeling an application. > > Often I see JS Libs like Qooxdoo, ExtJS and other with loading times > like this at the init time > > 2-3 Seconds network transport > 1-3 Seconds initialization time (middle of stopped time and "feeled" > time) > 1-3 Sec. data loading (init lists with data and so on). I always thought that the biggest bottleneck is the initialization time. But I see, it may differ from use-case to use-case. For sites which are not regulary used the initial transport is quite important. Sure. > > > At worth it took up to 6-8 to start working with an application. > Nobody > dies in this timeframe, but it doesn't feel fast. Another thing which slows down current applications is the number of images and other resources which gets loaded. Latency is often more problematic than size. > > And from my point of view, qooxdoo often feels a little bit slower > then > other. At most, this is pure illusion, but illusion works. For > example, > Extjs seems to build the comps one after another, the display > "flickers" > more then in qooxdoo. Doesn't make a big difference, and not what I > meaned in my first mail, but it's part if the "feeling". A customized qooxdoo build really helps to let qooxdoo shine. Often this dramatically reduce the transferred file size as well. The flickering is unacceptable for me. I don't really think that many users prefer this over our current solution. But the flicker in Ext has another reason. They sometimes rebuild the already rendered site. It feels faster maybe because there is happing something on the site. You can do the same with some type of progress dialog. Maybe some 0.8.x version will have better support for such features. All in all the flickering slows down the whole thing. When there is one thing we have learned until now, it is that it is faster to not let the browser do some reflow. This especially slows down the whole thing the more complex, the more rich, the sourounding content get. > > > What I now mean, and what you answered in parts, is the network > loading > time. > The splitting of the application sounds, even if I don't understand > (even with the docs) how the applicaton will find the correct way to > split it off. Could you explain this in more detail? You define one class per dialog/part (normally the main controller class for this part). It recursively analyses the dependencies of this part and later brings all results together and starts the magic ;) > > And does it means that qooxdoo is part of all of the splitted parts? Some classes of qooxdoo maybe part of one class, some others may be in other parts. The main idea is to reduce the overhead of the initial startup (which also mean that this package could not contain all qooxdoo classes, this would result into a conflict to reach this goal). > > > I think the splitting of qooxdo from the app code (if the app code is > one or more files isn't what I mean, but sounds nice) is very > important. > If the user keeps a stable qooxdoo version (and who won't in a live > app?), the user doesn't need to reload it when only the app code is > changed. I don't see that point in your mail :) Ok, ok. Maybe because I think that we need to pay one bill. It is a question of what is important for you. Generally it should be possible to keep qooxdoo completely outside of your application classes. This should be easy with the new generator. This may lead into a better cachability of qooxdoo through different sessions because it does not change very often. But it has one major negative point: Initial execution time. The parsing and creation of qooxdoo classes you only use in parts of the application the user maybe never uses today. Then the user pays this with a decreased loadtime. In my opinion it is the best to deliver qooxdoo fine-grained with the packages which needs qooxdoo classes and let the packaging do it's magic. In my opinion download speed is less problematic than execution speed. Also there are still other places to optimize download speed. qooxdoo 0.8 will come with support for combined images which nearly automatically improves performance at the factor network time a lot. > > > Also the JS result code client side cache optimizing seems not part of > the new build system, but I think some small optional server side > logic > could improve it alot, together with pre-gziped js files (that can be > delivered correctly by the server side scripts without mod_gzip on the > server). People have so many different backend systems. I don't really see the point here. It is better in my opinion to collect some good documentation or write own articles to help users with such a requirement. Most enterprise users already have solutions here (like they have CDNs and/or image servers etc.) But I am still happy when you share your experiences. We can easily collect some of these scripts in a special qooxdoo-contrib to make colloboration between different authors and companies a breeze. > > > And last but not least; I really think that the versioning is a good > think to improve handling of the code. With differen js code > filenames > we could activate absolutly every freaking client side / proxy side > caching system and can thrust on the delivery of the most up to date > version at the same time. An never under 150 KB+images qx app should > allways try to be loaden as rarely as possible. > > At a normal webpage 150 KB (gziped) files are not a big problem, but > qooxdoo (and other js libs) need to do some rendering after that, and > this is slowered at start then pure html code. So we should reduze the > loading situations of the base files as often as possible. And I > really > think that creating a solid design for the delivery of the qx apps > should be part of qooxdoo. Ok, I definitely see your point. It is a good idea to have something to offer here. I would really like if you can help us here. Write some articles regarding your ideas to our wiki (it is open for everybody) and if you like, I could also register you a new qooxdoo-contrib project to put your files in. > > > I know that everythink I talked about can allready be done. I allready > tried to build my own small separate qooxdoo file, try to exclude > qooxdoo from my app code, gzip the js files, have PHP code on > serverside > for client side caching and so on, but why not put these in qooxdoo? > Seems to be problems that others have, too. > > Please, correct me if I'm wrong, and more then that write who others > do it. > > (The caching of the files in build process sound very nice, I hated > the > building in the past, every improvements is wonderful :) ) Even better: It also work for API data generation. It is blazing fast now as well. > > > So be absolute clear, my three main situations I see ways to optimize: > > 1. When the app code is changed, but qooxdoo not (possible that > 2. Idiot save client side caching (with server side logic and file > names > with version number attached), that make it also easy for the > browser/proxy to find only changed files (in my example only 2, but > if I > understand you right then more in the future with generator2) > 3. And improve gzip handling by adding it the the build process. Do you really think that it helps to directly writeout gzipped files? We can easily add it, at least to the new toolchain. > > > And again the mail is longer then I hoped ;) :) Greetings, Sebastian > > > Greetings, > Leander > > Sebastian Werner schrieb: >> Hi Leander, >> >> one thing to differenciate is the loading time (network transport) >> and >> the other the initialization time (creating classes, properties, >> objects). After this there is the runtime (e.g. reactions on mouse >> clicks). >> >> Two split the resulting compiled file into multiple files does not >> reduce the complete size and this way not the initialisation time. >> What exactly needs to be done is, to split the file according to the >> usage in the application. I will try to explain in one example: Your >> application may have a preferences window which uses widgets which >> are >> nowhere used, but there. In a normal qooxdoo build all classes, even >> the ones from your preferences window a bundled into one big file. >> Following this example the basic idea must be to split an application >> into the logical parts (main window, preferences, accuout-manager, >> etc.) not in the source groups (e.g. qx and application code). >> >> It is possible to solve this in 0.7.x by using custom generator calls >> but it is some work to find the ideal groupings. (Documentation: >> http://qooxdoo.org/documentation/0.7/custom_builds) >> >> In 0.8 we will introduce a new build system (if all went well). As if >> our list for 0.8 isn't already long enough, we add another major >> improvement: Semi automatic packaging. Each dialog and part of a >> application simply gets registered in the build configuration file >> and >> the system automatically manages the loading of these parts. Commonly >> used classes are automatically grouped together as well. >> >> The new system also use a new caching system and other major >> improvements. Rebuilds of already build software (just a few classes >> modified) are done in seconds, not minutes. >> >> Both of your suggestions are doable with the new system easily. >> However in my opinion there are better ways. >> >> Preliminary documentation is available here: >> http://qooxdoo.org/documentation/general/generator2 >> (trunk only at the moment). >> >> Regards, >> >> Sebastian >> >> >> >> >> >> Am 27.02.2008 um 15:21 schrieb Leander Hanwald: >> >> >>> Hi all, >>> >>> I'm currently think about who to speed up qooxdoo load time. One of >>> the >>> main problems for most (I think ;) ) is the big JS file itself, not >>> the >>> runtime. >>> Beside the option that you could use gzip I see other ways to >>> speed up >>> the loading. >>> >>> The most "annoying" part of a build process for me is that qooxdoo >>> builds everything again and joins it again. But why exactly produce >>> qooxdoo ONE big file, instead of 2? >>> I mean, why is qooxdoo and the project linked together? From my >>> point of >>> view it's not very usefull. When a Project is changed (and most >>> project >>> will do this more often then they change qooxdoo), the qooxdoo >>> part is >>> reloaden by the client as well. >>> I understand that loading 100 files is slower then 1 file, but >>> loading >>> two files instead of one file shouldn't be a great difference. Also >>> other projects like ExtJS load up to 5 files for itself, and they >>> still >>> loading faster then qooxdoo (the the online demos). >>> >>> My idea would be the following: >>> >>> Source >>> qooxdoo.js : This file contains all classes of qooxdoo and is >>> generated only one time, or when user requested >>> [project].js : This file includes the qooxdoo.js and the single >>> classes >>> of the user >>> -> I think that would speed up the load time of the source version, >>> now >>> he loads hunderts of files which is often slowered (when I tested >>> it) >>> then loading all classes. >>> >>> Build: >>> qooxdoo_[version].js : Like above, but if the uses selected it only >>> with >>> the needed classes. Regenerated only if needed >>> [project]_[version].js : Combined and optimized Project files >>> loader.js : This file is included the files above. The version >>> number is >>> to show the browser definitly when a js file is changed. >>> -> If php/perl... is involed then the loader.js would load the >>> script >>> adove through the php/perl... scripts . >>> -> The loader.js could be skipped if the index.html is >>> autogenerated. >>> >>> There is one big advantage of the build version splittet these >>> files: >>> The Browser can now check if the files are changed separatly, and >>> load >>> only the changed one. If qooxdoo is not changed -> don't reload it. >>> For >>> most projects this would be a speed up on change by at least 50%, in >>> smaler projects much more. >>> >>> Version number: The idea behind them is that you could set the >>> client >>> side cache to nearly unlimited, so the browser doesn't looks often >>> (never? <- is that right?) if a file is changed and uses the cached >>> one, >>> until he sees the request for a file he doesn't now by name. >>> >>> Also it would be nice if qooxdoo could generate the gzip Version in >>> the >>> build process as well, and also produce php/perl/ruby/python loading >>> scripts to choose the right JS Version and set the browser caching >>> as >>> well. I could write some PHP Scripts that helps here. >>> >>> I know that this is nothing for qooxdoo 7.x, but for 8.x it seems >>> "sexy" >>> for me. >>> >>> What did the rest thinks about that? >>> >>> Greetings, >>> Leander >>> >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> qooxdoo-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> >> >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
