Peformance Improvement in Google TreeMap API

It was so much fun, to play around with Google treeMap API over a month. Currently I'm working on an application which heavily uses this API , to handle  huge amount of  data retrieval from the back end. It was trivial, to figure out a way to improve the performance of the application, which was heavily dependent on this on line Google treeMap. The answer was to draw the hierarchical information layer by layer of  the tree Map, as in each left click , there will be a server call to retrieve the  next level data set.
(Anyhow, if you want to get started with google API, they have provided a cool on line example which you can try out  first and understand the depth of the API very fast. It will brief you how dose it load and prepare a whole set of data array to populate  in each layer at one shot.Also this example helps out to understand how to organize the data array to draw it layer by layer)

So,  in my business problem, the application uses Google API to show some code dependency change information.So the treeMap has  used to show case which piece of code unit  (package,classes,methods) of a code base has changed and it indicates the heaviness of the change with  a defined color code. Here we have made an assumption that we analyze dependencies for  a code base which is written either java/.NET. In the TreeMap,  first of all,  I would see the module level changes of a project. As I drill down, the treeMap will show, the next level changes. For example if you see the module level changes now, modules includes packages, so in the current layer it will indicate that there are changes in packages level with a reddish color range .Likewise it will show the changes for ,classes  and method as well.

Drawing two layers to show changes in the treeMap , doesn't  harm the left click event and  it  helps to drastically improve the performances of the application.But, the problem comes when you roll up, on the right event which always need a parent level with data  to be rolled up to the next level.So once you right click on the method level changes(roll up( )) ,and tried to see class level code changes it will work out.But when you right click (plain) again on classes level and roll up to the package level,  the right click event will not fire. Then you can't view the package level changes in backward.

It's quite challenging to customize an API  and stop running certain features which are already featured to have with it and designed. Trying with a dummy parent also didn't work out to trigger a right click event at upper level , when it doesn't have a parent. Basically,  the solution was to draw the tree map single layer by layer. So, that you can assume,  there is no such a parent layer at all.
What would remind you the following picture ? Some color play on a puzzle game? or else Wesak?;) You name it what ever it pops in your mind. Anyways,  Isn't it beautiful color combination?

Technically, trust me when I say that each and every small piece of squares indicates a code unit (package,class or a method ) according to my business problem. The lager squares, separated with a white color border are indicated the present layer  component,a package.( Since  I  have already drilled it down to one layer bellow from module level). So yellow to Red color code range indicates, that there are code unit changes in other bottom layers. Data capturing for a change of code unit is done by using another propriety, third party tool . The google tree map is simply used  here to present the data in a proper hierarchical structure.

Even though,  you go for the option of drawing tree map layer by layer ,  in  parallel, there will be a server call  for each layer to draw, which dose the data population. If your server calls are heavy,  that will automatically drop the performance of your web application drastically. So it should be a careful thinking ,analyzing and moderating google treemap to enhance the performance of it in  this way.

Rescribere sentias!

Some one would  search for my blog title to understand the meaning of it. I'm sorry, if I mislead you to assume it's an  English title. It's Latin but English. Meaning is that " I feel to write again". It's a new start, so I opened up a new blog, with the feeling of streaming out what I have been working  in my tech life for last couple of days,weeks, months and may be over the years!!
It was being little hectic for last couple of months,  to work late to up and run a web application which used google API treemap to visualize  some code analytical data,dependency changes and impacts of a code base. Google API  is  pretty smart of course for small web applications which don't have huge data volumes to handle or the frequent server calls. Having said that, using google API   in industry based  web application solutions,  do live with  multiple drawbacks. It's needed the Internet to fetch with the API at run time of the application. On the other hand it fails to handle massive number of data population because the tree draws at once with entire data  set and that data needs to be loaded at first time to the view level.As a result of that, web application  hits on the  performance. I have used about 60k odd data set  in the tree map, to test the application performance, which took about 1.5 minuets to load and draw the treemap, in this single plain   application.
The eye catching feature of google tree map API was that it's articulation  with flash. It 's the newest API enhancement, named as "DrasticTreemap" which is pretty much attractive feature.
Migrating from google tree map API to drastric API is quite simple and straightforward.
In case, if you are interested to get your hands dirty ,on line examples are the best options to start and explore about google API  tree map and such  other charting. This has become very popular API in today, to use in web based software solutions such as mobile applications, air reservation systems and many other on line based applications.