Lazy Loading

I am currently on a project that deals with Leases and Loans. It’s a really big project with about 60 people working on it. The customer would use this product to create thousands of organizations, leases, loans etc. and millions of assets, payments, charges etc. Going by the scale of the application, it should be apparent that performance would be a bottleneck. Yes it is !!
One of the most complicated screens in the application is the LeaseSchedule Screen. It contains 14 tabs and more than a hundred widgets. With all the SQL queries optimized, it still takes about 13 seconds just to bring up the screen !! The analysts want the screen to be loaded within 5 seconds. Now that’s asking for too much, right?

Hari, Saket and I decided to work on this card. Looking at the server console, we found out that it took 4 seconds to execute one main query where it creates the screen’s model. We concluded that we needed to tame this beast. Looking at the code, we saw that the screen initializes the model and then draws the GUI, populating the widgets with the data obtained from the model. Seems normal eh?
Well, we didn’t think so. We wanted to render the GUI independent of the model. This is where the idea of lazy loading came in. Firstly, we removed the use of the model in all the UI methods. We then initialized all the dependant models separately and collated them into a separate thread. Now, the UI would render separately and at the same time, the models would be created in another thread. With these changes the screen now loads in 2 seconds !! It actually loads in 3 stages which is clearly visible.

1. The GUI is rendered with all the widgets, without any data.
2. The data obtained from the model is populated into these widgets.
3. The security features are applied to every widget.

The total time taken for the screen to be usable is still over 10 seconds, but the UI is rendered within 2 seconds. The user can now get to see the screen immediately, instead of waiting hopelessly without any visible response to the mouse/key events. I strongly recommend this approach for screens which need to display a lot of data.
But then came the final twist. We spoke to the client, telling him about the what we had achieved. He was very much impressed, but asked us not to implement this feature as of now, coz he perceived quite a few bugs to creep in due to these changes. Since we are very close to the end of the release, he told us that this would not be the appropriate time to incorporate these changes. We were told to document the approach, and probably implement it in the beginning of the next release.
After doing all this, it’s disheartening to revert all the changes. But I did learn quite a lot while doing this.