Re: More questions than observations on installman

Replies are listed 'Best First'.
Re^2: More questions than observations on installman by davido (Cardinal) on Feb 23, 2011 at 19:39 UTC
That being the case, it's a good thing that installman fits into the category of "seldomly run." It makes a lot of sense to "optimize the hell out of" something that gets frequently used. But if that ten percent savings amounts to two minutes per install, and there is one install done per month, the total annual savings is 24 minutes. We spend more time than that in a week, tapping our fingers on the desk waiting for our computers to awaken from sleep mode. I ++'ed this thread because I enjoyed the discussion as well as appreciating the curiosity that lead atcroft to look into installman's performance issues. But it almost seems like in the end it just is what it is: Something that processes thousands of files once, once in awhile. While on the one hand it's surprising there's no smoking gun, on the other hand, highlights the topic of the complexity of managing to pull POD/MAN out of a large number of source code files in a way that is flexible and doesn't break anything already out there in the wild. If there is any approach that has a chance of significantly improving things, it would probably be to throw out the current solution and re-implement from scratch, taking care to not break things. Whether this would actually be productive I have no idea. Perhaps another solution that could save some time when installing on top of existing installations would be to keep the teased out POD's/MAN's, and verify them against a checksum from the source such that if the source changes, then we pull a new page out. But if there's no change to the source (as evidenced by the checksum) the previous version which is already installed will remain in tact, and nothing will be regenerated. Since it's unlikely that everything changes at once, this could save some time. But it may show my inexperience on the matter to assume that such an approach is even possible. Dave	[reply]

Replies are listed 'Best First'.

Re^2: More questions than observations on installman
by davido (Cardinal) on Feb 23, 2011 at 19:39 UTC

That being the case, it's a good thing that installman fits into the category of "seldomly run." It makes a lot of sense to "optimize the hell out of" something that gets frequently used. But if that ten percent savings amounts to two minutes per install, and there is one install done per month, the total annual savings is 24 minutes. We spend more time than that in a week, tapping our fingers on the desk waiting for our computers to awaken from sleep mode.

I ++'ed this thread because I enjoyed the discussion as well as appreciating the curiosity that lead atcroft to look into installman's performance issues. But it almost seems like in the end it just is what it is: Something that processes thousands of files once, once in awhile. While on the one hand it's surprising there's no smoking gun, on the other hand, highlights the topic of the complexity of managing to pull POD/MAN out of a large number of source code files in a way that is flexible and doesn't break anything already out there in the wild.

If there is any approach that has a chance of significantly improving things, it would probably be to throw out the current solution and re-implement from scratch, taking care to not break things. Whether this would actually be productive I have no idea.

Perhaps another solution that could save some time when installing on top of existing installations would be to keep the teased out POD's/MAN's, and verify them against a checksum from the source such that if the source changes, then we pull a new page out. But if there's no change to the source (as evidenced by the checksum) the previous version which is already installed will remain in tact, and nothing will be regenerated. Since it's unlikely that everything changes at once, this could save some time. But it may show my inexperience on the matter to assume that such an approach is even possible.

Dave

[reply]