Can anyone tell me if there are any performance overheads to using the dataset designer as opposed to setting up the data connection using code and manually retrieving the data?
-
You mean besides the terrible overhead of the dataset to start with? I know no serious developer handcoding data access code - and no serious developer using datasets except for dynamic scenarios (reporting, user selectable fields etc.) – TomTom May 02 '10 at 10:47
-
So what is the overhead of using a dataset to start with ? – Paul Michaels May 02 '10 at 11:01
-
I quite often see reference to the overhead of strongly typed datasets but have never seen any figures backing this up. Anyone aware of any good info on this? – Martin Smith May 02 '10 at 11:03
1 Answers
When you use the designer to create a dataset (XSD), you are creating a "typed dataset". When you can, use typed datasets over creating them in code. A typed dataset improves your ability to maintain your apps. Instead of referring to your data columns by a string name, you can refer to them by compiled properties.
Instead of...
Dataset1.Datatable1(0)("UserId") = 1
you get...
Dataset1.Datatable1(0).UserId = 1
It may not seem like much, but you eliminate the chance that somewhere in the code you have misspelled your column name. There are many other benefits.
As far as performance is concerned, you won't notice any runtime performance difference whether you build them with code or the designer. The designer generates code from your XSD file anyway. However, for very large amounts of data in memory, you are better off designing a custom class for more efficient resource use.
The short...
- It is worth using typed datasets instead of non-typed datasets because of the development/maintenance benefits.
- Most of the time you won't notice a problem with performance if you use datasets.

- 11,857
- 5
- 62
- 68