Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

simple question 1

Status
Not open for further replies.

IonelBurtan

Programmer
May 25, 2001
601
0
0
RO
Is there a way to determine the size of a reference type object? I saw that sizeof in .NET can only be applied to value types. But how can I find out the size of an instance of a class object?

Thanks,

s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...
 
Yes. The actual memory ocupied by the object in bytes.
Like the sizeof operator from C++.


s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...
 
there is a sizeof operator in C# as well, but it can only be used with value types, and only in unsafe code.

The size of a reference type is always exactly 4 bytes. The size of the object it references however, you'll have to figure out on its own.

Can't you just sum the lengths of the properties of said object? Why do you need the size in bytes?
 
Yeah, I know the size of a reference is just 4 bytes. It has some pointer behind it.
Summing all members size is bad programming style, I want to apply this to all kind of objects, nut just one.

But what I am interested in is the size of the actual object. And I really need to know that, it is not just a programmer whim for the memory allocator treats differentelly objects that are grater that 80k, allocating them in a place where they never get dellocated even on garbage collection (is in MSDN)

Thanks

s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...
 
There may be an article in MSDN by now. But at a local user group a guy from Microsoft did a presentation on this, and it was basically (for a reference object) 34 bytes plus the size of the data, plus the size of the inter-object padding to make it align on a CPU word.

Note that this value is for v1.1 of the framework, and will likely change for v2.0. If you write code around this value, be aware that it could change at any time, should Microsoft decide to.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
summing the members isn't neccesarily bad programming, as you can dynamically loop through the members of a class.
 
Thanks guys.
Yes NeilTrain, I did remember about Reflection that could help me to loop to the members of a class. It may be a solution but is quite tedius though as there are other things in a class besides simple types members. (events, delegates etc)

So, at this moment it seems to me that there is not 100% reliable method of finding the sizeof of reference object (a class instance)
This is quite strange for MS, they used to be careful with this type of details. About Microsoft's guy declaration it is not something to rely on when programming as he is talking absolute figures and I do not think this is really useful, too.



s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...
 
So, why do you care, anyway?

Often, making one call to a framework method will result in hundreds of objects being created and disposed of for your benefit. Do you plan to count them as well?

If you're trying to reduce your memory footprint, you might be better off creating many small DLLs, each of which will load into a non-overlapping memory region (a property on the project), and have good locality of reference, so that unused dlls can be unloaded when they're not being used.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
Ok, I will explain my reasons fully:
Once again, I do not care about the size of other collateral created objects.
The reason that I want to know comes form another "breach" in MS structure for NET arhitecture. They say in MSDN:

[blue]
The .NET memory manager places all allocations of 85,000 bytes or larger into a separate heap called the large object heap. This heap consists of a series of virtual memory blocks that are independent from the main managed heap. Using a separate heap for larger objects makes garbage collection of the main managed heap more efficient because collection requires moving memory, and moving large blocks of memory is expensive. However, the large object heap is never compacted; this is something you must consider when you make large memory allocations in .NET.

For example, if you allocate 1 MB of memory to a single block, the large object heap expands to 1 MB in size. When you free this object, the large object heap does not decommit the virtual memory, so the heap stays at 1 MB in size. If you allocate another 500-KB block later, the new block is allocated within the 1 MB block of memory belonging to the large object heap. During the process lifetime, the large object heap always grows to hold all the large block allocations currently referenced, but never shrinks when objects are released, even if a garbage collection occurs. Figure 2.4 shows an example of a large object heap.
[/blue]

Now an ASP.NET application stub of MS(aspnet_wp.exe) crushes when the upper limit for memory allocation is reached and this happens quite often on a medium application with 10 simultaneous users(at about 15-20 minute), losing every information like session and other stuff for all of them.

Any ideas?

s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...
 
perhaps holding the data in the session state is a bad idea? It sounds like your running a web server or web service app. Keepin objects, especially large ones, in memory is bad practice. Either dump them to the user as soon as they are created, if possible, or store what you need in a database, and get it as needed.
 
IonelBurtan,

That's a very interesting point. We had a fire fight at a .com company so we built that app really fast and without considering performance. The datasets we used were large and couldn't figure out why memory crept up until we recycled. I wonder if this is why. It would be nice to know which objects were on which heap and ways to avoid them going to the large heap.
 
Thanks for this valueable link. It is the closesest think I have now to the actual problem.

s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top