Hi Thomas, On Wed, 20 Jul 2011, thron7 wrote:
>> I am wondering what size to expect for the qooxdoo build cache. >> >> For one of our applications we get about 660 MB of cache. Which increases >> to about 1.2 GB when building another application. >> >> 1) Is this size what to expect? > > Indeed, this is not unusual. Building all apps in the SDK, with Apiviewer > and Testrunner for the framework, the 1.5 cache is about 1.3GB of size. > For every class used in an app there are multiple syntax trees in the > cache (one for the unoptimized tree, others for the variant-optimized > trees), compiled versions of the class code, possibly for different sets > of optimizations, and other class information like its dependencies. The > trees alone can get big. Considering we have 700+ classes in the > framework, plus a couple of hundred application classes, this easily > amounts to a couple of thousands of cache objects. Ok. It might be worth mentioning somewhere in the docu, as the default OS tmp dir might be on a RAM disks that usually is not that huge. I am using a "scratch" partition now for my cache which has the advantage of "surviving" a reboot (on the laptop at least this happens often enough). I don't really see a big performance decrease with that either. > But we have an issue open for this (bug#5241), so will look into it. Hmm, if it can be smaller, fine. On the other hand, I'd think performance is what matters most in this context. >> 2) Are different applications using different cache files? If so, there is >> no advantage in having the same cache for several apps, or is there? > > Different class files have different cache files. So if you have two apps > that both use the same framework classes, they share the framework cache > objects. Ok, so having a common cache would help in the first build of the second application. > To be more exact, they share it if it is the same class (file > system path), using the same *variants* and the same *optimizations* (for > the compiled cache items). If any of those parameters differ, the cache > item cannot be shared. I guess this would mean if I don't fiddle with config.json, those parameters should be the same. > But keep in mind that sharing is not only between different apps, but also > between different builds of the *same* application. This is another > important aspect of sharing. Re-building the same app would be much slower > without the cache. Isn't this the main (if not only) purpose of the cache? That's why I don't want to loose it at reboot (I have almost 3 minutes for a build with clean cache and about 6 seconds thereafter; a really big improvement, even if most of the development work can be done with the source version). Cheers, Fritz -- Oetiker+Partner AG tel: +41 62 775 9903 (direct) Fritz Zaucker +41 62 775 9900 (switch board) Aarweg 15 +41 79 675 0630 (mobile) CH-4600 Olten fax: +41 62 775 9905 Schweiz web: www.oetiker.ch ------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
