Yes we could do all these optimizations. We're also looking at reimplementing this (somewhat easy) process in Java to better control the parallelization.
This is the sort of things where our (too) basic tests didn't surface these issues so we're slowing going to fix them. On Tue, Feb 25, 2014 at 11:54 PM, Max K <[email protected]> wrote: > Thanks for the reply! > Turns out, that Kaspersky is scanning aapt on each access. That makes it > around 60k file operations on the same aapt file. I guess I'll need to talk > to the responsible guys for an exemption... > > Re calling aapt for every file: Couldn't you reduce the number of calls by > spawning multiple aapt processes and let each process work on a pack of > files? I don't know what the command limit is, but that could be determined > on runtime I guess. Or divide the files to be worked on in an arbitrary > amount of temp directories and let aapt run on directories instead of > single files again. At least for the inital task run. As you noted, > consecutive task runs are much faster. > > Anyway, thanks for the support! > > Am Dienstag, 25. Februar 2014 18:39:41 UTC+1 schrieb Xavier Ducrohet: >> >> Gradle will call aapt to process the png one at a time indeed. This >> allows us to only process the ones that have changed in further builds. >> Eclipse will call aapt on all the resources and will reprocess all the >> pngs, every time. >> >> You can try to edit one png and see the compile time in Eclipse and >> Gradle. The resource compilation should take a lot longer in Eclipse (make >> sure the post compiler step is not disabled as this is when it happens). >> >> That said, calling aapt from Java, for every png, even in parallel is >> stupid and we want to fix this. Calling aapt just once would be possible >> but we would run into command line length limit if we passed all the files >> we want to process. >> >> Gradle stores file mostly in 3 locations: >> $PROJECT/build : this is the main output folder. If you have several >> module, they all have their own build folder. >> $ROOTPROJECT/.gradle : cache folder. Only one even when using 2+ modules. >> $HOME/.gradle: system wide gradle cache. >> >> >> On Tue, Feb 25, 2014 at 2:06 AM, Max K <[email protected]> wrote: >> >>> Hi, >>> >>> I'm currently working on a transisition from eclipse to Android Studio >>> and therefore also to gradle. By now I got my build scripts (multi-project >>> setup) working nicely. >>> I'm facing a big problem though. Some observations: >>> >>> - gradle calls aapt for each and every png file to optimize it >>> - It does this in parallel though (4 processes, 4 core CPU) >>> - ~1250 PNGs >>> - I use the same build tools in both eclipse and gradle (latest) >>> - I currently have to rely on the plugin 0.7.3 as 0.8+ breaks my >>> complete build (other issue) >>> - My anti virus has a policy set with one exception. The dev's >>> projects directory. >>> >>> Building my project in eclipse takes around ~2 miutes from a clean >>> state. Building the same in gradle takes around ~10 minutes. >>> I tracked it down to my antivirus using substential amount of CPU and >>> HDD power to scan (temporrary?) files. Comparing to the eclipse debug >>> output, it seems that eclipse does NOT call aapt for every single png file. >>> >>> Are my assumptions correct? Does gradle store the files it is working on >>> in a different directory? It seems that eclipse doesn't go outside of the >>> projects directory as my antivirus doesn't kick in. >>> Is there any setting I can set to limit gradle build execution to the >>> specific directory? >>> >>> Relevant log: >>> 10:24:28.937 [INFO] >>> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] >>> :main:mergeDebugResources (Thread[main,5,main]) completed. Took 8 mins >>> 36.895 secs. >>> >>> Thanks. >>> Max. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "adt-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> Xavier Ducrohet >> Android SDK Tech Lead >> Google Inc. >> http://developer.android.com | http://tools.android.com >> >> Please do not send me questions directly. Thanks! >> > -- > You received this message because you are subscribed to the Google Groups > "adt-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- Xavier Ducrohet Android SDK Tech Lead Google Inc. http://developer.android.com | http://tools.android.com Please do not send me questions directly. Thanks! -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
