dimension <di*******@discussions.microsoft.com> wrote in message news:<97**********************************@microso ft.com>...
Thanks all for your feedback.
My concern is performance. So let's take this approach...
assume i don't know a thing about Structs and used them improperly, would
the worst case scenario be that i end up with basically a memory footprint
similar to a class? Are accessing methods or and properties more efficient
for one verses the other? (I know in most cases this would not make a
difference...but assuming i need to do mass processing of 10000 objects)
btw, i like the suggestion by one responder with regard to having a Factory
object keep a DataSet/Datatable in memory and returning class objects or
struct types only when needed. great idea and actually would reduce round
trips to the database, as it would be sort of like a caching mechanism.
thanks!
In answer to your specific question, if you use structs incorrectly
you can produce absolutely horrible performance. Remember that every
time you assign a struct to a variable or pass it to a method you
create a copy. Sometimes this is exactly the behaviour you want: you
want your structure to act like an elementary type like an integer or
a decimal type. For example, I created a struct called Fraction that
has three integer fields: WholePart, Numerator, and Denominator. I
made it a struct because I want it to act exactly like an integer or a
decimal: assigning a fraction to a Fraction variable makes a copy
rather than having two variables share a reference to the same
fraction. However, the penalty I pay for this behaviour is that every
time I pass a Fraction anywhere or do any mathematics with it, I copy
three integers.
Classes behave differently. Whenever you assign one class variable to
another class variable (called reference variables), you simple copy a
reference (a pointer) from one to the other, but they now share the
same object.
There are fundamental differences between value semantics and
reference semantics in .NET. IMHO, you should not choose one over the
other because one is "more efficient". You should choose to use
structs rather than classes because your design calls for value
behaviour. You should choose classes over structs because your design
calls for reference behaviour (which is almost always the case). I ask
myself, "Is this thing I'm building like a basic value, such as an
integer or a double?" If the answer is no, then it's a class; if the
answer is yes, the it's s struct.
I don't presume to speak for programmers writing software for true
real-time systems where every clock cycle counts, although, as I've
said in other groups, if you're writing for that kind of tight
environment then I question why you're using a language with a garbage
collector, but anyway.... My take on making these decisions based on
"efficiency" is that you should do this only if you must, and only
then if you have a deep understanding of the consequences of choosing
structs over classes (value semantics over reference semantics), or
vice versa.
You can gain far more performance improvement by using appropriate
data structures and improving your overall design than you can by
making tweaks like choosing structs over classes. If you build your
application and find that it doesn't perform well, THEN profile it and
figure out where the bottlenecks are. Creating a big software mess
trying to shoehorn structs into an application in the name of
"efficiency" is generally not productive and can, as I pointed out
above, jackpot you in the end with inefficiencies that you weren't
counting on.
Design for clarity, then use the constructs that logically follow from
your design. You should deal with small-scale efficiency problems
after your application is running and you know where the problem areas
are, otherwise you're just firing blind.
