http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660A lock-free algorithm is slower than an uncontended monitor (uncontended monitors are really fast)? that doesn't surprise me at all ... try it with 8 threads running on a dual quad core and you should see a difference. generally lock-free structures will actually perform worse in situations where you run on a single processor. Cheers, Greg http://ayende.com/3271/the-cost-of-abstraction-part-iii#comment5http://ayende.com/3271/the-cost-of-abstraction-part-iii#comment5Mon, 28 Apr 2008 17:36:13 GMTJulien, In the readonly keyword case, it has meaning beyond the perf scenario, which are importnat http://ayende.com/3271/the-cost-of-abstraction-part-iii#comment4http://ayende.com/3271/the-cost-of-abstraction-part-iii#comment4Tue, 22 Apr 2008 08:44:54 GMTFollowing your blog post, I recently had the same kind of conversation with a co-worker about the readonly keyword and its performance impact. I had to made some micro-benchmarking myself to get numbers, but basically the conclusions are exactly the same as yours: don't use that kind of techniques to speed code execution! More infos on http://www.thedotnetfrog.com/2008/04/22/performance-impact-of-the-readonly-keyword/ http://ayende.com/3271/the-cost-of-abstraction-part-iii#comment3http://ayende.com/3271/the-cost-of-abstraction-part-iii#comment3Tue, 22 Apr 2008 07:02:04 GMTHi, Just wanted to contribute to this interesting conversation. I'm from the "don't optimize prematurely" school of thought. Premature optimization is waste of time - making right decisions upfront is not waste of time and should be practiced. Now it is not a rocket science to make good choices upfront, just follow widely adopted and well known good practices and you're good. Someone said in earlier posts that he decides to use "optimized" algorithm upfront, seems as the safest example to hook on to. On contrary I tend to choose simpler and easier to understand then the state of the art rocket speed algorithm if it is more complex. First of all if you make part of your code twice as fast but it is contributing with less then 1% in overall execution time figure yourself if you wasted weeks of effort (count in maintenance here, which we often forget). And if you followed all the best practices then you can easily swap algorithm if it becomes a bottle neck, right? At the end, one thing easily forgotten is proficiency of your fellow developers. Not everyone is able to understand your highly optimized code. I would like to use in my work new languages which are more fit to purpose then what we use today, but it would be only me who knows how to use them: so I learned about this problem first hand, and it isn't to be left aside. I'd have lots more to write on the subject but I'd say understandability before optimization is my choice. Cheers, Mihailo http://ayende.com/3271/the-cost-of-abstraction-part-iii#comment2http://ayende.com/3271/the-cost-of-abstraction-part-iii#comment2Thu, 17 Apr 2008 17:32:11 GMTIn my experience when you encounter more complicated examples than this the hardest part of making code more performant is understanding the code. The slight performance penalty you get making the code more flexible will probably pay itself back as soon as you need to resolve a real performance bottleneck. http://ayende.com/3271/the-cost-of-abstraction-part-iii#comment1http://ayende.com/3271/the-cost-of-abstraction-part-iii#comment1Sun, 13 Apr 2008 09:13:57 GMT