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
