Idea for a speed improvement in css file handling

[mauritslamers]

After implementing the file manager, I was partly surprised that the speed improvement was rather limited. After doing some profiling, it seems that part of the issue that in my project the BT takes 33 seconds to start is because it takes around 26 seconds to do the css file parsing.
The profiling data shows that the parseContent function is executed twice, the one without the x2 option takes 12 seconds, the one with 14.
My impression is that it should be possible to cache a few things which are not influenced by the x2 option.The current implementation does the entire transform from raw content till product twice, but is this actually really necessary?

[mauritslamers]

Looking a bit through the code I also notice that the file API is not always used fully. As an example, in https://github.com/sproutcore/build-tools/blob/master/lib/file_types/css.js#L362 the basename and extension of the file are recalculated, but both are implemented as cached properties on the base file object. This only needs to be done once.

[mauritslamers]

See for a few improvements https://github.com/sproutcore/build-tools/commits/filemanager.
In my project it has reduced the launch time of the BT from 32 seconds to 23 seconds. Please review!

[nicolasbadia]

After testing, I was having an issue with modules which can be fixed by this: 3b75911

I'm also having issues with languages when building my app. My app should be build in 2 languages and everything goes in an any folder.

[mauritslamers]

Language support is indeed broken, as I have been re-implementing in such a way that the language becomes flexible in dev mode. This turns out to be a missing feature from abbot, where adding the language code to the app you can force to see the app in a certain language. This is something I think is very useful. This reimplementation is not done yet.