Angular Application Performance Fixes — Story #1

You know, being in programming job means — once in a while — you come across a bug — what I call a Mirage Bug. And solving such bugs is actually one of the joys of programming troubleshooting — the interesting journey of striking out all the false positives and zeroing in on the real culprit.

I had the luck of coming across and solving one such mirage bug today.. So I thought I will share the journey with you as well.

Today, one of my team members reached out to me saying that their application — which uses PrimeNg Datatables is irrationally slow on IE11 “once the data table renders”!

Demo of PrimeNg Datatable Angular Component..

He presented me his analysis which included reference to a number of github issues claiming PrimeNg Datatable had performance issues ( even at smaller number of rows and columns ). This is a season of IE11 Angular performance issues and this particular analysis worried me. I have come to love PrimeNg library and its simplicity. And here was a big blow to my belief in that library!

In a screensharing session, the developer showed me the unbelievable plight of his IE window.. literally reeling under the load of rendering a simple datatable.. and … and I was sold to the idea that the bug really really exists with data table and somehow PrimeNg — a very fine library — somehow has done a super shoddy job in designing their data table — which cannot even load 20 rows x 6 column table without chocking the browser!!

While he demonstrated the issue — I ignored other signs which I should have paid heed to. e.g. He had to choose couple of dropdowns before hitting a button that brings data for Datatable.. and the application seemed just a wee bit sluggish when he tried to open the dropdown to select one item out of it. Had I questioned that behavior — I would have saved 3–4 hours of my life.. but I guess I wouldn’t have been exhilarated at the end like I felt now!

So.. since I could not find any issue / reason for such behavior of Datatable on IE.. I asked my developer to allow me to do my own debugging in my little corner. After spending 2–3 hours reading through various github issue descriptions for PrimeNg datatable and analysis about Data table performance issues.. all the issues seemed to be fixed by v4.1.0 and we were already on v4.1.2 and that is what was baffling me.

Finally I took out last tool in my arsenal —Divide and Rule . I knew if this does not work, nothing will! I started clearing the out all specialties of DataTable, checkbox column, inline editing, selection.. suspecting that one of it causing IE to trip! But no matter what I was doing IE was stuttering and my machine’s CPU usage was going out of the roof. Even when I was not even touching IE! Ta da! And, after several minutes it hit me.. What if I am looking at wrong place for wrong person? What if it’s IE’s high CPU usage (due to some other cause) was THE culprit affecting Datatable rendering in IE?

Now I started checking exact event which triggers IE to have high CPU usage and I was terrified to see that IE had high CPU usage right from the home page rendering — which hardly had 2 buttons along with bunch of static text and images (apart from header and footer). Forget PrimeNg Datatable, I really started doubting performance of Angular itself on IE11 now!!

Again, I continued my divide and rule strategy to finally isolate the issue in lamest component in my entire application — Footer Component — one which had just 4–5 links! If I comment out that component.. world is a happy place again!

God, what is happening in the world! What on earth could we possibly write in harmless footer component that grinds entire application to halt!! Anxiously, I started going through the template and component code for footer .. and there it was… sitting patiently for me to find him ngAfterViewChecked() implementation laughing at me.

The Angular Lifecycle hooks!

ngAfterViewChecked gets called automatically by the Angular rendering engine automatically if component properties change. And this particular implementation was changing one of the component properties via setTimeout() thereby triggering another call to ngAfterViewChecked.. which was again causing another call to ngAfterViewChecked and so on.. in an infinite cycle!

I simply adjusted the implementation to work without ngAfterViewChecked and boom, we were in business! World was a happy place again! Angular application was working fine in IE without a hitch! PrimeNG Datatable was a high quality component without rendering issues for simple usecase like ours! It was our own 6 lines of code that was making our life miserable!

I had fun in figuring it out and I hope you had too!

I will come back with more such stories of performance improvement / fixes for Angular App.. Keep reading. Subscribe to my channel to get notified about new stories from my side!

Oh and hit claps as many times as you could to keep encouraging me to write more!