Best Can Still Be Improved

In my project, I am also one of the guys working on re-architecting one component. In fact we saw this component performaning very well when we put it in use, but still we wanted this to be more powerful, faster and robust. You can say, we are religiously following the saying “Best can still be improved”. Our component is now able to process 34 records in 1 second, but our expectation is to boost this up to 60-70 records per second. We have few challenges to operate on now, optimal performance, scalability, loosely coupled for easy integration with other components/applications.It is like, tie your hands behind your back and fight! If I am thinking of loose coupling, I have to compromise with performance, if I ignore scalability, I will have simple design which will have less layers (tightly coupled) and execute faster. I term this as a circular problem, if you do one thing other will get screwed and if I take care of other, main thing may not work as expected. But, what’s the fun if problem is not rigid? Right now, performance is the highest priority for us. We are identifying the areas where we can improve performance and later we can think of scalability. As of now, we are tweaking the code written and optimizing for less memory and CPU cycle consumption, efficient multithreading where ever it fits properly, because creating too many threads may give negative results (too much is too bad), creating isolated application domains for better stability, creating shared components and making sure it is of single instance irrespective of how many clients refer it, avoid too many method calls, use try-catch blocks intelligently, have single database connection and reuse it efficiently, make minimum database calls…what else..? We are thinking and exploring…