Readable output. Methods are however minimized into one-liners in order to easily get an overview of the code. If you want to see comments and everything, you can view the code on the github project page (0.4/builder/inc/methods/[method-name]). Besides the commented code, you will for most methods also find a file describing the implementation and the conciderations behind the implementation
Optimized for gzip-size by hand. Each method has been manually input to Google Closure compiler and in addition various tricks has been applied.
Optimized for execution speed rather than size. For example there are certain DOM-methods, which are only available for some of our targetted browsers. These DOM-methods perform better, but it produces a bigger file to test for the availabilty of these methods, use them and also provide fallback. Right now, only minimal work have been done to optimize for speed.
Inlining of helpers
With this option selected, there will be no inlining of helpers. You will rarely want to use this option, because it will be better in every respect to choose the option below. This option is mostly here for testing purposes
If a function is only called once, it will in all respects be better to inline that function than not. With this option selected, helpers only referenced in one place, will be inlined, but otherwise they will not. This strategy produces the smallest possible uncompressed file. It will also consume the least memory. And I guess the ungzipping will be slightly faster
Optimal inlining-strategy according to the "Optimize for" option above. When optimizing for speed, all helpers will be inlined. When optimizing for size, most helpers will be inlined, but not all. The cost of repeated code is very low with gzip, which means it generally produces smaller gzip to inline than not. However, if the helper is big, it is better not to inline it, gzip-size-wise.
(Speed-optimal inlining). All helpers will be inlined, so there will be no helpers, actually. This option is optimal speedwise, as there will be no overhead of calling a function.
The CDN is set up as a pull server. If the build is already on the CDN, the CDN returns it. If not, the CDN contacts the picoQuery builder and then caches the result for 100 years. It is set that high, so you can rely on CDN working even if the builder is temporarily down. Note that while its often handy to just point to a CDN, its better performance-wise to either inline picoQuery in your HTML or concatenate it with your other scripts
The idea with this format is that it allows you to choose methods without visiting the builder. Ideal when your project is work-in-progress - you simply add method names to the URL, as you need them. When your project is finished, you can grap the code and inline it, or visit the builder URL available in a comment in top of the code in order to get a shorter build URL. The order of the methods does not matter.