forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Reducing Forrest build time
Date Tue, 09 Aug 2005 08:57:07 GMT
Diwaker Gupta wrote:
> As Forrest grows and becomes more complex, we really have to watch out for the 
> build times, and think of ways to reduce the build time. I was doing a build 
> today of site-author, and it took ** 35 minutes **
 >
> Now I might not be running the most powerful machine out there, but its decent 
> -- 1.7GHz centrino, 512 RAM. Seeing the build process eat up ~100% of the CPU 
> for a half hour straight was not a pretty sight.

There is a problem with Forrest at the moment that is likely to be 
causing this. See Davids message about this.

> What do other devs feel about this? Is this something we should be seriously 
> looking at? Atleast I feel we should be. What are the best ways of 
> approaching it? (avoiding building unchanged document is the obvious first 
> step I guess)

Obviously addressing the above issues would be the first step.

> Also, the site-author build currently generates 783 pages. Do we really need 
> all those pages? (I'm just thinking aloud here, so feel free to disagree).

At present we build all three sets of docs (0.6, 0.7 and 0.8-dev) all at 
the same time. There is no need to rebuild the 0.6 docs anymore as they 
will no longer be edited. These could become a static site now.

There is also considerably duplication between 0.7 and 0.8. If we 
leverage the locationmap to only have copies of documents in 0.8 that 
are different from those in 0.7 then Cocoons caching would come into 
play when generating these duplicated docs.

But wait, no it wouldn't because the MOTD appears in the body and that 
would change between the two versions. We could solve this by only 
having the MOTD in the site menu part (hence body-*.html would be cached).

> I 
> understand that we need to demonstrate Forrest's power so its good to have 
> different output formats available, but can't we just have a "demo" area 
> showing different output formats for different input formats (like we have in 
> the fresh-site).

We do, all plugins documentation is separately generated. There is still 
plenty of stuff in core that could come out into a plugin. That will 
help reduce things.

> Do we really need to carry around all of the other PDFs 
> (other than the fact that Google might have indexed them) -- perhaps an 
> analysis of the server logs will help us make those decisions.

Not for the whole site no. But I think they are important for some parts 
of the site (documentation mainly). Unfortunately Forrest, as it stands, 
cannot create PDF links on some pages and not others. Forrest:views 
solves that, so we need a PELT version of forrest:views and then we can 
reduce the number of PDF's generated.

> Just testing waters here :)

Thanks for bringin it up. Perhaps you can add your/our ideas to the 
Issue tracker. Otherwise we will just lose them.

Ross

Mime
View raw message