Etherpunk

I'm in the process of getting an app going under .NET 3.0 using Visual Studio 2008 to see the differences in speed between Linq, SubSonic, and using a plain SQLDataAdapter. Yes, I'm well aware using a DataReader / DataAdapter is going to be faster -- the question is: How much faster? Is it worth making the code that much more cleaner? What about if the code is only going to be used once 4 months from now and, hopefully, never touched again? My problem is I want something to be as fast as possible without making code ugly and without spending a lot of time tweaking -- so I'm taking the shotgun approach. At the moment, it seems like they are all fairly close unless you are dealing with LOTS (millions) of records -- which I am not. SubSonic has its fair share of bugs such as puking if a table doesn't have a primary key. I can understand it not understanding how to right back or do complex queries, I just want to populate a collection with a 'Select *' type statement -- so it doesn't need a care about primary keys as I'm just going to loop through item in the collection and pull data as I see fit. Also, SubSonic seems to always do a 'SELECT *' type query if I want to use the simple code such as 'Some_DB.Some_TableCollection TC = new Some_DB.Some_TableCollection().Load();'. If I want to be specific then I have to use a Query class. Even worse, it's /horrible/ at doing OR's. They really prefer you to use views or stored procedures. Neither of those are bad, but I'm not writing code for something anyone else but me should be using -- so I don't care about exploits or any safety measures. Even if I was, this engine doesn't have any direct input mechanism, so good luck with that. Linq seems overly complicated. Fucking A is it a bitch to setup. Nothing seems automatic. Code doesn't /feel/ cleaner (so far from my, admittedly, little testing). Google doesn't seem to know how to use it either. I'm finding contradicting information. So, this means I have to do a "best case scenario" speed test to get both Linq and SubSonic working, which isn't a bad idea. One of the programming styles I learned was "assume everything will work perfectly, *then* make exceptions". The alternative, which is more common, is plan for the worst then if it's the best do X. The problem with that is you are always occurring the overhead of the worst instead of doing the best first and if it fails (Which it rarely should) then go to some exception handling. This places me back at square 1. Here is my game plan:

• Have a script which will populate a database + table with random data. This way nothing can be cached and you can regen as needed. This will probably populate a 'person' table with 2 million records. This is a small amount compared to some other databases, but for our instance it should be plenty to test for speed.
• Write a GUI which has a listbox and a DataGridView. The listbox will contain different methods of getting data from a SQLServer to a DataGridView. The hope being that if I can get it from a SQLServer to a DGV then I can be fairly certain nothing got cached and everything got pulled over for data manipulation.
• Write a a few tests. These tests will probably be a simple SubSonic, Linq, and SQLDataAdapter. I will later do more complex queries and embed them to attempt to bring out slowness or resource hogs. SQDA and SubSonic will be the first two. Linq will be third, and any other complex queries will be last.
• Open source the program and release to world under BSD license.

I'm also probably going to try some of this code on other DB engines such as MySQL and SQLite.