ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Brown <tpbr...@gmail.com>
Subject Re: ivy:buildlist and parallizing build
Date Fri, 08 Jul 2011 20:48:30 GMT
Hi Jonathan,

I've messed with this challenge with varying levels of success.

The primary issue is if you're changing a few modules (say A, B, and C) and
those modules have interdependencies (say C depends on A).  If you go
parallel, C is likely to resolve the old version of A.

Not saying it can't be done, but to make things simpler the last build
pipeline I did in this manner: 1) identify changed modules and build/unit
test them in order (serially), 2) identify impacted non-container modules
(jars, etc. that depend on changed modules, directly or indirectly) and
process them fully parallel , 3) identify impacted container modules (war,
ear, etc.) and process them in parallel.  (not using subant, btw -- just
"runtarget" from ant-contrib and overriding a few properties)

However -- if you're still building to or from a standard disk (or SAN, or
NAS) then you're more likely to get a much bigger benefit to moving over to
SSD to RAM than you will from parallelizing individual modules builds - and
much simpler too.

I normally see commit builds in an I/O bound situation which slows them
down. Try running your build from /dev/shm and see what kind of performance
difference you get.

HTH,

~Tim


On Fri, Jul 8, 2011 at 1:40 PM, Jonathan Williams
<spamhammer1234@gmail.com>wrote:

> Hi,
>
> We currently use Ivy:buildlist + subant to build a large multi-module
> project. As the project grows, the topic of parallelization has inevitably
> come up as one of the ways we could speed up compiles. A search on this
> topic has shown some interest in implementing this in the past, but nothing
> recent or concrete as far as results go. Does anyone have a solution for
> this, or are we SOL?
>
> -Jonathan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message