Optimizations in Bugdar 1.2.0

Over the past few weeks, I’ve been working away at Bugdar 1.2.0 and I’ve noticed that the release isn’t going to be as feature-centric as 1.1.0 was. Instead, in 1.2 I’m putting a lot of emphasis on optimization. There, of course, will still be some important and highly-requested features added (namely custom column display and saved searches) but most of the work will be spent on optimizing the code. Bugdar 1.2 is almost done, save one feature that I’m still investigating–which I’ll talk about later.

Some of the minor optimizations are putting conditions around queries to make sure they don’t get executed unless really necessary. But by far the biggest speed improvement I added yesterday:

I made a drastic improvement to the template system that speeds up Bugdar’s average page loading time by roughly half a second. In previous versions of Bugdar, a page would typically load in about 0.7s – 1.0s. Via debug mode, I could see that rougly 0.2s – 0.5s of that time went to caching templates for display. I thought (wrongly) that this was because it was loading templates directly from the filesystem, and the disk access was causing the slow-down. However, after investigating a little, I discovered that the processing and parsing of the template was the true culprit.

To speed up this process, I added code into ISSO’s template system that queries a list of requested templates from the database cache table. If a record exists for a given file, it then checks to make sure that the timestamp stored in the cache is greater than or equal to the last modified time of the actual file on the disk. If it is, then it simply returns the pre-parsed and pre-processed template from the database. If not, then it loads and parses the template from the filesystem and puts it back into the database so that future page loads use the newly-cached template.

While this is relatively minor change, it has drastic consequences for speed: the template caching process is now on average 0.004 seconds–a 100% decrease in template processing time. This improvement makes Bugdar feel much snappier and will reduce the time it takes to load a page, and it will reduce the work put on the server. Now, a Bugdar page completes loading in about 0.1s – 0.4s.

As for the last major feature for the 1.2 release: I’m investigating a workflow system. What this would do is it would allow an administrator to define a strict path of statues that a bug would follow, allowing it to only be advanced one step forward or backward at a time, limited by the assignee of the bug (or the group of the assignee of the bug). The back-end work is relatively little, the major problem occurs when figuring out what to filter and what not to filter, etc. on the user-end display (showreport.php) and what to control when saving changes to a bug. This was a user-requested feature so it’s not as fleshed-out in my mind as it could be (as I didn’t think of it), so if you have suggestions or input, let me know.

I’m not making any guesses as to when Bugdar 1.2 is going to be released; major work is nearing completion, but it really depends on the workflow feature and then squashing any bugs found in the beta cycle. I am aiming, however, to have major work completed by the end of the month.