> On 19 Aug., 12:00, FND <[email protected]> wrote: > > > I've been able to squeeze an other 91kb out of the last version > > You might wanna read up on minification vs. packing, Wolfgang. > This might be a good starting point: ...: >
> So we have to decide what's more important - filesize or startup time. > While the former has always been an important factor (though perhaps > mostly psychological), it might not be worth sacrificing performance for. > > We'll do some profiling of our own to determine how significant this > difference really is. > > On 29 Jan., 15:33, Saq Imtiaz <[email protected]> wrote: > > I think profiling is definitely needed before a decision can be made > on this. Note that TinyTiddly has been using the minified "slower" > type of compression since the beginning and no one has noticed or > remarked on any difference in performance as compared to the regular > version of TiddlyWiki. TinyTiddly may also prove useful for purposes > of profiling the performance effects of minifying. > (http://tinytiddly.lewcid.org) > Has any profiling been done? - before the decision was made due to the following reasons: > On 5 Feb., 16:58, FND <[email protected]> wrote: > After some deliberation, we think that using the packed version in the > TiddlyWiki core is not a good idea: > * web servers usually support compression via gzip > * the decompression is fairly slow in JavaScript[1] > * packed code makes debugging very painful > * packing can introduce bugs > * packed scripts are almost impossible to read, which breaks TiddlyWiki's > "view source" paradigm (even though minified scripts are compressed as > well, the obfuscation isn't as comprehensive) > * packing requires additional effort when creating a release > * the jQuery team doesn't provide a packed version anymore, and creating > a custom derivative should generally be avoided > Hmm.. I would still be interrested in the results of profiling. Because all reasons against higher compression seem to me more concerned with fears which never came true by using Saq's compressed version for years now, or developmental reasons which for me - as a user - don't count. Filesize is a major factor with no high speed internet ... for most in Brazil, Nigeria, India.. > > Wolfgang, I would be interested in any ways to further reduce the > code but I really don't buy into the whole packing idea so would > rather not do it this way.. > Jon > I followed Saq's advise of using a combination of JSMin, Shrinksafe and Packer. Which I found in combination here: http://compressorrater.thruhere.net/ Last time and the core of the 2.5.2 version rising above the then filesize limit at compressorrater - I used JSUtility for the fist time with good results too: http://jsutility.pjoneil.net/ But I've no idea how to use these automatically.. Regards.. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en -~----------~----~----~----~------~----~------~--~---
