Another day, another challenge 🙂 One of our customers has reported she is trying to import a large MPP file and it takes forever to complete. Alex tried his best to fix this, but he hit the wall of unknown requirements, so the task landed in my list.
And what a task … when I’ve first seen the code, I couldn’t believe my eyes: what is all this code doing here, what’s its purpose? It turns out Eddy has again manage to define some cloudy requirements and the developer tried her best to match them (although they made really, really no sense). I’ve explained the PO the situation and tasked her with bringing Eddy to his senses. Of course she did, she’s a smart girl. So we’ve dropped all weird requirements, I’ve dropped the unneeded code, went on improving the sequence that was creating a hierarchy from a flat list and … the MPP load time dropped from 20 minutes to 17 seconds on my dev machine (i5, base SSD and 16 GB of RAM). Not too bad 🙂
While checking the timings, I’ve noticed something really, really odd: the 12K rows from the MPP file were read in 2 seconds, my newly implemented hierarchy builder was taking 20 ms, so where are the other 15 seconds spent?
Well, another requirement from Eddy that the developer was not able to properly implement: the list of original items has to be stored as a tree in the DOM, otherwise deleted items do not preserve their position. The original developer didn’t have time to properly implement it, she just made it work (so in the original code we had two sequences building hierarchies from flat lists, both using naive algorithms; they worked acceptable for MPP files having about 1000 items and nobody bothered testing larger files).
I’ve properly implemented this code sequence as well (remembering in the process that inserting values in a hash table is O(1) and not O(n*log(n)) 🙂
And now the huge file import sequence requires 7 seconds!
I’ve created a special build, asked the QA to validate it and went on to solve some personal problems.
When I’ve returned to work, the QA was all shining, except for one tiny detail: while showing the MPP data in the import wizard runs blazely fast, once the user closes the wizard the rendering process takes forever. On this one, I can’t say when shall we be able to improve the situation, since PowerPoint is STA. The only idea I have is to run a background thread to create shapes in advance for a shapes cache structure; this way, when the rendering process starts, the most expensive operation (shapes creation) is skipped.