http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@Ayende: I guess I go test but does NHibernate really load the entire contents of a bag when you add an item? http://ayende.com/2452/architecting-for-performance#comment5http://ayende.com/2452/architecting-for-performance#comment5Wed, 20 Jun 2007 12:02:33 GMTGoing to try to find time to link to this later but just wanted to say that this post was very well said and I agree with pretty much all of it. http://ayende.com/2452/architecting-for-performance#comment4http://ayende.com/2452/architecting-for-performance#comment4Tue, 29 May 2007 19:09:29 GMT@Casey, I think I did write a little out of context. My point was simply that "optimizing" for performance in advance in my opinion is a huge waste of time. Designing for scalability and performance is always important, after all we are developers and this is a big part of the job. I use the word "optimize" meaning to squeak out that extra bit of performance and I use word "design" meaning understanding your domain, data volume, and data usage as Ayende pointed out in his post. I still feel some of Ted's points were about tweaking for microseconds. Yes NHibernate has some overhead compared to a straight sproc and datareader but it has considerable advantages, and how much slower is it presenting a 100 row datagrid from a reader, dataset, and domain object. I would guess the datareader would be pretty fast but is the comparison between NH and DataSets, probably not that much different as DataSets have a lot of overhead? Now jump that up to a 1,000,000 row table with paging. How quickly can you get it to page efficiently with the previous three methods? I have also seen Criteria queries in NH generate far better performing SQL than some complicate sprocs. Think about advanced search cases... I have to agree with Ayende that its about making decisions that cause the “least amount of pain”. This is a very subjective statement and in some shops it may mean doing everything in the DB and in other shops it will main building a domain model. I would bet my hat and a bowl soup that a consultant walking into a project done with logic split between sprocs, triggers, and code versus a DDD project with an ORM and unit tests would take the DDD with smile because they would imagine the pain and struggle of tracing all the logic through code -> sprocs -> triggers. Another big point lost in this whole argument is that NH brings with it the DDD approach which is based around a ubiquitous language. NH & DDD projects tend to be very self documenting and much easier to dive into and find out what’s going on. Besides, NH is just pure magic so why waste energy, time, and money doing something it does automatically. In the end it’s about delivering to your customer, who doesn’t understand any of this anyway, and giving them the best solution for their money. Do you really think your customer gets more bang for their buck if you have to write and maintain sql code, data access code, and application code? I would love to see cost, time, and code metrics on projects done with ADO.Net vs ORM. KISS && DRY Adam http://ayende.com/2452/architecting-for-performance#comment3http://ayende.com/2452/architecting-for-performance#comment3Tue, 29 May 2007 17:31:08 GMTThere's nothing wrong with designing and coding with performance in mind - as long as you understand performance issues. Too often I've watched people start writing some code in an obfuscated way, saying that they're doing it like that because it's important for 'performance' and not caring that this piece of code will run once per day, would normally take about 10ms of CPU and isn't going to be noticed by the user. It's not really impressive to get a 1000x speedup in that situation. The other problem with their code tends to be that they don't even write comments to say why their design is so strange. I think this is because they realise that if they explained it, they'd have to admit they were wasting their time doing something they enjoy and that they thought development was about (hacking) rather than doing the less exciting but more important stuff which development is really about (building in an easy migration path for the new feature, getting the tab order right in the user interface, testing the code actually works). Sorry, rant over! http://ayende.com/2452/architecting-for-performance#comment2http://ayende.com/2452/architecting-for-performance#comment2Tue, 29 May 2007 15:06:12 GMTI think Adam either didn't word his statement well, or misquoted the accepted maxim ... You don't OPTIMIZE till last. You ALWAYS design and code with performance in mind. The more experienced you are, the more likely that the second will become second nature and you will do it without needing to think too much about it, but no matter how experienced you are, you cannot optimize until last. http://ayende.com/2452/architecting-for-performance#comment1http://ayende.com/2452/architecting-for-performance#comment1Tue, 29 May 2007 07:00:54 GMT