6

I'm making a 2D platformer game and to represent a level I'm using 2D array of tiles which are classes with fields for position, type and various flags. When I change the class key word in the tile class to struct, a loaded map consumes about 20% less memory.

I don't know about rights and wrongs of this action, I just want to know why the difference in memory consumption.

Edit: numbers are 1038 MB with tiles as classes and 845 MB as structs (without most of game data).

user1306322
  • 8,561
  • 18
  • 61
  • 122
  • Because .Net structs are "lighter weight" than .Net classes. 20% seems a bit excessive. But creating (for example) 1,000K instances of a "class" object *will* use more memory than creating 1,000K instances of an equivalent "struct" object... – paulsm4 Aug 15 '12 at 19:18
  • 1
    It looks like you might be considering using mutable structs (if I understand the "flags" variables). For your own sanity, don't. http://stackoverflow.com/questions/441309/why-are-mutable-structs-evil – spender Aug 15 '12 at 19:18
  • Here's a ton of info on class vs struct: http://stackoverflow.com/questions/521298/when-to-use-struct-in-c – Almo Aug 15 '12 at 19:19
  • Correct. It's also important to note that if you start moving the instances stored in the array between functions make sure to pass by ref... or.... just use classes. Because the copying of data is sure to slow things down. – Matt Razza Aug 15 '12 at 19:19
  • What are you using to gather this metric? – Peter Ritchie Aug 15 '12 at 19:20
  • PS: spender is correct. mutable structs *are* evil. But I don't think that's the problem here (otherwise, you might be seeing *more* memory for structs, not *less*). – paulsm4 Aug 15 '12 at 19:21
  • 1
    Your 20% figure is hard to interpret because you didn't tell us how many bytes of payload are in each struct. – David Grayson Aug 15 '12 at 19:23
  • 2
    1GB for a tile-base map in a game is a little silly in any case. – harold Aug 15 '12 at 20:01

3 Answers3

11

An array of objects is actually an array of references, and the objects are stored on the heap.

That means that there is an overhead of 4 or 8 bytes (depending on x86 or x64) for the reference, and then there is an overhead of 8 or 16 bytes for each object on the heap.

In an array of structs, the struct values are stored directly in the array, so there is no extra overhead.

So, if your data is for example 48 bytes, the extra 12 bytes (in x86 mode) would be an overhead of 20% of the total memory used.

Note that there is also a difference in how they are used. If you move tiles around or send one as a parameter to a method, all the data will be copied if you use a struct, but only the reference is copied if you use a class. If you can keep the struct smaller than 16 bytes, the performance difference is small, but if it's larger you may get faster code by using classes.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
3

Each object has an 8 byte header containing a pointer to the type handle and a syncblock index, whereas structs are allocated inline. In addition, you need to allocate a pointer-sized reference for each reference type variable you're using.

This article goes into the details of how objects are created an laid out at runtime.

Lee
  • 142,018
  • 20
  • 234
  • 287
1

A storage location (variable, parameter, array element, or field) of a struct type holds the values of all its public and private fields, typically concatenated but possibly with some padding. A storage location of class type holds a (possibly null) reference to a heap object (4-8 bytes). A heap object holds 8-16 bytes of overhead plus the contents of all of the public, protected, and private fields held by the object and its ancestors.

If the things you are storing are fixed-size bundles of values, you should most likely use a struct with exposed fields. The notion that structs should be immutable goes back to days when a C# compiler would take a piece of code like:

  readonly Point Pt = new Point(3,4);
  void Yippie() { Pt.X += 5; }

and have Yippie construct a new temporary Point, copy Pt to it, call the X property setter on that temporary instance, and then discard it. Someone figured that the proper way to prevent such nonsense was not to have compilers say "Sorry--you can't call a property setter on a read-only struct variable", but instead to define structures so as to have read-only properties without setters. The proper thing to have done would have been to require that any struct methods or properties which were going to mutate this indicate so in their declaration and forbid the use of such methods or properties on read-only structs.

Wrapping struct fields in properties will impair performance, and I would recommend against it except in cases where one needs to enforce struct invariants. I would also recommend that one avoid declaring structs readonly, since any structures so declared will be copied in full any time any field is accessed.

Incidentally, an important thing to beware of with mutable class types: the state of a mutable class object not only includes the contents of its fields, but also the set of all references that exists to it. In some cases, this can be useful. Often, the only way to prevent major headaches is to have entities which hold references to mutable objects refrain from sharing such references. If making something a class type would require extra work to prevent references from being passed around promiscuously, that's a good sign that the type in question should be a struct.

supercat
  • 77,689
  • 9
  • 166
  • 211