Thursday, April 9, 2015

Learning Assembly Language

For self-improvement I decided to learn assembly programming. Funny where a "Yellow Brick Road" can take you. What inspiration lead me to assembly? The Jargon File of course. Can't quite recall how I stumbled upon the Jargon File, but that lead me to want to learn assembly programming.

So far I'm reading this tutorial on the subject. I haven't done any of the programming yet. There is a try-it option which is great; however, it doesn't quite work out on mobile which is how I do my research for convenience. Don't you know there's already been a bit of payoff though? There has.

I was struggling with an existing feature in an app that had performance issues. It was caching html in a db as a result. When the user navigates to the page and opens certain sections of the page, an Ajax call was being made to load the html from the db. We needed the html to be built on-demand in order to implement a new requirement.

After updating the code to build the html when the user opens section, I noticed performance issues. After some investigation, I saw that there were anywhere from fifty to a hundred database calls (Intellitrace is a great tool for this). No wonder there were performance issues - database calls in loops and recursions will certainly have an adverse affect on performance. I had to improve that.

Thinking along the lines of assembly code where values from memory are loaded into registers (built-in memory in the processor), the solution was to load all the values into memory from the db and switch all the logic to operate on the in-memory data. This wasn't as difficult as it sounds.

All data that was used in the html was coming from 5 tables. Those tables contained meta-data. At most, any table would have about 250 rows. In the builder class, I added a IEnumerable member for each entity type. In the class constructor, I loaded all the values that would be used to build the html 5 calls to the db total.

Since we are using Entity Framework and Linq, it was just a matter of encapsulating each call to the db and switching from context.EntityCollection to _entityCollection in all of the calls. The same Linq statement applied except for the .Include statements. I didn't end up having any problems in that respect though since all the included entities were loaded in the initial calls (I lied about the number of tables, but most of the others are 1:1 anyways so not logically separate tables).

For example:

...
context.People.Where(p => p.IsActive == true && p.GroupNumber == groupNumberParameter).OrderBy(p => p.LastName).ToArray();
...


became:

...
_allPeople.Where(p => p.IsActive == true && p.GroupNumber == groupNumberParameter).OrderBy(p => p.LastName).ToArray();
...


By reducing the number of database calls in a similar way that assembly programming can be more efficient by reducing the chatter between processor and memory (interrupts) programming at a higher level will be more efficient. Of course memory pressures may result if you aren't cognizant of the demand so there are some caveats as always.

No comments:

Post a Comment