Estimating memory use of a class instance

I have an app that uses a class (clsPopulation) which describes the state of my data. The data changes in a step-wise manor. I want to keep a history of each step. (kind of like Photoshop) I assume I must create a copy (not a reference) to this class at every step and store it in a collection class. Or perhaps use a different class that contains only the data, not the methods. Retrieval must be through copy to, or the history would be compromised as the referenced record would be updated with the restored class. Lots of code... Does anybody have any suggestions born of experience? How might I estimate how much memory this history might need. Or should I just implement it and see?
Thanks!

Classes have a fairly large per-instance overhead compared to the alternative, user defined Types.

Additionally, user defined types do not have an issue with references vs cloning (a = b creates a shallow clone, every time)

The space requirements for an array of UDT's can be fairly trivialy calculated:

first = lbound(UDTarray)
last = ubound(UDTarray)
bytes = (1 + last - first) * LenB(UDTarray(first))

essentialy, bytes = the number of elements times the size in bytes of a single element. A UDT that contains 4 integers (2 bytes per integer) would require 8 bytes per element.

It is important to note that UDT's can be padded by the compiler to a size a little bit larger than what is apparent (this is done for performance reasons)

The array descriptor itself also has a small bit of overhead but doesnt amount to much.

If a UDT contains variable-length strings, each string only officialy occipies 4 bytes (a reference to the actual string) and the overhead for those strings will be much larger. I would urge that you use a fixed-length string instead. This issue extends to a UDT containing a reference to a class, again a 4 byte reference is stored instead of the actual class data.

I simply must get out of the habit of creating a new class for every solution! Upon re-examination I realized that the only data that really had to be saved was an array. A good example of overcomplexificationism resulting from insufficient planning. I learn...