Disadvantages of re-inventing the wheel

In web applications displaying search results in a nice list with all sort of options like paging, sorting and export filters is a common scenario. There are many third party commercial and opensource products addressing the problem. But in very huge product you will always find a custom in house solution to this.

Same is the case in the company I work for. We have our own ListTag to address the problem. It has paging and sorting built in to it. Recently I came across a performance issue regarind a page which was displaying search results from the page. When there were more that 1000 results the page took forever to display. Everyone natuarally was pointing to the database query and there were many solutions proposed.

But I wasn’t convinced, I put in timers to calculate how much time was spent querying the database, populating its results in POJOs and then displaying it to the user. To my surprise the whole time was spent displaying the results to the user. I went inside the ListTag code to find out why was it taking so much time. And what I saw was total horror. All the things from display to sorting was custom built. There were tons of calls writing HTML using response.write using + operator for string concatenation. My first task was to get rid of these. After fixing all this there was significant improvement but still it was taking a lot of time. I found out that the whole time was now spent in the sort function, so naturally the disection was inevitable. I saw several sort fiucntions like IntSort, StringSort, DateSort etc. for sorting things based on the type of the data passed in. Looking at the sorting algorithm I was amazed, It was the basic bubble sort. All the things cleared out and I could explain exactly what was the bottle neck. I immediately replaced bubble sort with QuickSort and the page displayed in a blink.

I am planning on to use DisplayTags (www.displaytag.org) for replacing our custom ListTag so that we don’t have to spent fixing these inhouse solutions. A properly tested solution meant for the problem is a lot better than re-inventing the wheel. Because we dont have to spent time fixing it up and there are updates avaialble for it which take care of the common bugs encountered.

Disadvantages of re-inventing the wheel

2 thoughts on “Disadvantages of re-inventing the wheel

  1. once we went for a in-house-built list tag when we wanted to handle lazy loading in lists with 10,000+ rows.

    by lazy loading in a list i mean: go an fetch when i press next button in a grid and do not fetch the whole data at once.

    maybe there are product with this feature but we did not find at that time!

  2. Faisal Feroz says:

    We had the same situation. But instead of writing the whole thing from scratch we just modified DisplayTags to handle the thing. We wrapped the table inside a form so that when someone pressed the Next Link a form was submitted which queried the database and returned results. Simple solution on top of DisplayTags 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s