Profiling my build speed, looking for hint

(Rudi Adianto) #1

Hi there,

Will be my first post, so greetings from the warm Indonesia.

I am converting a hybrid ant-maven build and now in the phase of ironing out the result.
One problem (well, at least to me it is a ‘problem’) that I have is that it still took too long for the war task to complete.

Eventhough there is only 1 JSP changed, and the result would be an exploded directory, it still take 16 seconds to complete.
In my mind it should be a lot faster since what the war plugin needs to do is sync that single file instead of doing whatever else it is doing.

Any hint on where I should look next?

P.S. not looking for being spoonfed :slight_smile: just a hint on where to look is fine. However I will not reject should somebody care to explain in detail.

(René Groeschke) #2


16s for packaging a war seems like a lot indeed. keep in mind that the war task is not synching a directory, but building an archive. Can you check how big your war got? seems like it’s packaging a lot of stuff.
are you maybe using a network share that slows down your file operations?


(Rudi Adianto) #3

Hi Rene,

It is indeed a big war; packs a lot of stuff.
The war archive is 200mb-ish, exploded war exceeds 300mb. Hundreds of JSPs, javascripts and web assets to be packaged.

Yes I can somehow sense that it is rebuilding the whole package instead of syncing.
So what I have in mind:

  1. modularize my project more such that portions of the web asset can be cached (i am speculating here, not sure if this makes sense at all :slight_smile: )
  2. create my own logic to deploy exploded war for development purpose.

I think the second option is my best bet, no?
In case I am going that route, what do I need to know to have up-to-date checking work?

Thanks before!

(uklance) #4

For option two I suggest you use a Sync task rather than Copy since deletes in the source locations will be applied to the exploded directory

(Stefan Oehme) #5

You can reuse the spec of the war task to create an exploded version instead, without first packing it. Packing is not incremental, which would explain the long times you see. Still, 15s for 200MB sounds like a slow file system, so something you might want to look into.

task explodedWar(type: Sync) {
  into whereverYouWantItToBe
  with war

(Rudi Adianto) #6

Using Sync instead of Copy does not help.
It still take long to synchronize exploded folder with source.
The project do have non-conventional directory structure, and what I do to assemble to complete war is this,

You guys spot anything that I could do better?

As for my workstation’s I/O subsystem, I believe it is fine.
My laptop have decent SSD, which Crystal Disk Mark test result shows:
4k block random read with 4 thread, 32 queue: 365MB/s
4k block random write with 4 thread, 32 queue: 300MB/s
4k random read single thread: 23MB/s
4k random write single thread: 100MB/s
Test file was 4GB (although i dont think test file size matters since SSD have no concept of cluster proximity).

(Stefan Oehme) #7

What file system are you on? I’m not sure Crystal Disk Mark will capture the overhead of the file system when operating on many small files.

(Rudi Adianto) #8

I’m on NTFS.
My workstation running Windows 10 Enterprise.

Do you really think that the filesystem make that much difference?
If you dont mind me asking, according to your experience how much time does it take to build a 200-300mB war (consisting of hundreds of web assets, 30-40 dependencies jar, and hundreds of classes) and what filesystem are you on?

By the way I am using Gradle 4.0.

(Stefan Oehme) #9

Absolutely, NTFS is slow with many small files. I don’t have a direct comparison project to measure against right now, but I’ve generally seen large copy tasks being 5-10 times faster on my Mac than on my previous Windows machine.