This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Performance rears it's ugly head, again
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Roy goes over some points pertaining to method inlining and performance here, and I just have to react. If your application is slow, it is NOT(!!!!!!!) because you didn't inline your method calls. This is true even for 99% of the real time applications out there. The number one reason is, always has been, and probably always will be, IO. If you're reading or writing from disk (this includes databases), or going over the network, or drawing something on the screen, it is ORDERS OF MAGNITUDE slower than sticking another method call into the stack. I've just finished up some consulting work for a high-throughput message processing system. Performance requirements were up high on the list. You know how we achieved them? By making sure that all IO work was safely kept out of the critical processing path - not by inlining some methods. Concurrent processing is the way to achieve ultra-high levels of performance - there's nothing faster than several things occurring all at once. The only way that concurrent processing can occur is if all the tasks being performed concurrently are independent of each other. That means that they don't share resources. This means we don't have to concoct elaborate locking schemes to make sure they don't step on each other's toes. So, while inlining a method call MIGHT decrease running time by several nano-seconds, it will almost surely decrease the maintainability of your code. If you really want to improve performance, take a critical chain view of the entire system - measure, identify the bottleneck, fix/improve, repeat until performance is satisfactory. And on the issue of multi-threading and performance, to quote Juval Lowy "nothing performs worse than a deadlock"....
Previous Topic
