Re: Array.Sort a struct

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"James Park" <someone@xxxxxxxxxxx> wrote in message news:%23oqOZBVKGHA.3728@xxxxxxxxxxxxxxxxxxxxxxx
"Bill Butler" <qwerty@xxxxxxxx> wrote in message news:MmWEf.674$Zy3.238@xxxxxxxxxxx

<snip>
So, why is it a bad idea in your case???

I'm not the OP, but that's okay. :)

Ooops, sorry about that


<snip>

Personally, I only use structs for P/Invoke stuff, but I'd like to know other situations where
they should be used. It just seemed to me that this could be a legitimate situation.

Many people come the C# with a C++ mindset and choose structs over classes for the wrong reasons.
They will ,by default, choose a struct over a class for a Plain Old Data(POD) type.
They do this because they think of a struct as a lightweight class ( ie faster).
They figure that they don't need that object baggage (methods and stuff)
In short, they do it to improve performance.
More often than not they actually get worse performance due to boxing and full copying on method
calls.

Objects access in c# is quite fast and most Properties will get inlined by the JITer, so POD types
should ,by default, be classes.

So, when should you consider converting your class to a struct?
Suppose you have a small object (not expensive to copy) and you create alot of them in tight looping
situations (a Point comes to mind.) . The potential performance improvement comes from faster
creation of the struct on the stack. This is offset against longer method call times (unless the
struct is tiny),and Boxing (although generics can help). So if you have tiny , immutable objects
that you create frequently and it is effecting performance, you MIGHT get a performance boost by
changing it to a class.
The important thing to note is that it is the cost of creation that you are saving. So structs
might help in short lifetime conditions. The choice should NOT be made lightly.

In C# the object should always be the DEFAULT unit of data storage.
In most situations it will outperform structs.

In the specific case of Gerrit's Playlist.
The data MIGHT be immutable (at least it is in his quick sample)
The data is NOT created frequently (he creates 1 for each file in a folder)
His struct is small but not Tiny (more expensive method calls).

So, He could use a stuct to represent his data and most likely only suffer a small performance hit.
Of course that depends on the actual logic.

The real point is that he probably chose the struct over a class in order to make it MORE
performant.
It is doubtful that the end result will bear this out.
This is why we tend to steer developers away from structs.

Bill








.

Relevant Pages

  • [PATCH update 2] firewire: fix "kobject_add failed for fw* with -EEXIST"
    ... There is a race between shutdown and creation of devices: ... Happens rarely (when shutdown of a device coincides ... container_of(work, struct fw_device, work.work); ...
    (Linux-Kernel)
  • Re: Whats WRONG With My Code ???
    ... > struct LinkList { ... The traditional approach is to separate creation of a list ... unsigned int data; ... C++ Faq: http://www.parashift.com/c++-faq-lite C Faq: http://www.eskimo.com/~scs/c-faq/top.html alt.comp.lang.learn.c-c++ faq: ...
    (comp.lang.cpp)
  • [PATCH update] firewire: fix "kobject_add failed for fw* with -EEXIST"
    ... There is a race between shutdown and creation of devices: fw-core may ... device pointer can't become invalid between lookup and usage. ... struct fw_device *device = ...
    (Linux-Kernel)
  • [D5] set folder creation date
    ... i have to set the creation date of a folder, ... Prev by Date: ...
    (comp.lang.pascal.delphi.misc)
  • Re: Lahman, how ya doing?
    ... >>>Responding to Hansen... ... >>>class EventElement ... >> have used a struct as a passive holder of data. ... it allows us to create instances which are immutable objects. ...
    (comp.object)