@Thomas: good point! The OS should already optimize the access to the file system. Though I'm not sure what different OSes do exactly. How many file descriptors are cached? For how long ? Which ones exactly - the most often used ones, I guess. Etc.
As Michael said the CPU intensive task is whatever ITextResourseProcessor does. Most of the times this is a compressor but the application can do whatever it see appropriate. For Wicket's own resources we use YUI compressor at build time. But this just minifies the resources, doesn't concatenate them. Later at runtime PackageResourceReference loads xyz.min.js instead of xyz.js when available in production mode. On Mon, Sep 9, 2013 at 12:30 PM, Michael Haitz <[email protected]>wrote: > +1 because compressing and optimizing them with compilers like google's > closure compiler is very expensive. > > >> Hi, > >> > >> At the moment when a PackageResource is requested in production mode > Wicket > >> always re-reads the file from the disk, then executes any > >> ITextResourceProcessor on it and finally delivers it. > >> This is true for normal resources and for bundles. I just filled > >> WICKET-5344 - bundles does all this twice per request. > >> > >> My question is: should Wicket do all this again and again for each > request > >> or we may add some caching which can be switched on/off with a new > setting > >> in IResourceSettings ? > >> > >> The benefits are: > >> - reading from memory is faster than from disk > >> - less CPU time (ITextResourceProcessor is run just once) > >> >
