Measuring the size of a .net Instance

Remon wrote:

Hey,
   we are doing a very performance-critical system.
I need to profile the speed & size of each object , method calls & so.

I have got some profilers , but non measures the object's size.

Do you have any method , library , etc.. to measure the size of instances of the classes ?
Also anyone recommends a good performance measurement / profiler for .net ?

Thanks in advance

is it Speed critical or Size critical ?

at what level ?

will it run on a device like an embeded system or a normal PC / server ?


in most cases I'd say write the app or a sample of the app and just see if it has a perf problem then look at what to tune.

due to GC and memory management trying to pin-down the size will be difficult at best and may not make it run any better.

things that tend to be the hogs and killers are the things that cause 2nd level GC events. or too many first level GC's

for example strings..... if you create and modify a lot of them you can consume a *LOT* of memory and have a lot of GC runs to slow you down.
sometimes you use StringBuilder() to fix that.
but any time you have boxing / unboxing going on you will incurr perf issues.
so look for that also.

you still have not indicated the "domain of the problem" in regard to
how critical the "size" and the "speed" are.

this leaves a lot of room for bad guesses and wasted time and resources.

for example:

is this embeded?

is it machine to machine level operations ?

is it machine to human ?

is it "Human life critical" as in a person could die if it fails ?

is it more size constrained than speed or the opposite?


generally in most code you trade one for the other.

like taking a loop and runrolling it you may make some code faster by making it larger.

so often the "Fast" code is large and the "Small" code is slower.

but how much that matters depends on the use of it.

so I'd look at how it's used and then see what the constraints are and then decide how to impliment the code.

that's if the need to lock down the size and speed are that great.

even in most games you spend the most work in things like painting the screen, user input is generally a factor of x10 or x100 or x1000 slower than the screen draw.

so you could write the userinput in script as long as the drawing system was fast.

just one extreem example of what I am trying to get at.

Remon wrote:

Hey figuerres, 
 
The system is both size & performance critical.
System should Parse about 10 BILLION Lines / day , store them into business objects for later processing & correlation & store them into DB.

It should be a big servers farm for this, still we have to be VERY careful while implementing the system.

it's .NET based, That's why you can't compare it to games programming .

It's Webservices & COM+ system. should recieves files, parse & do some business over it, then store everything (Results & lines into DB)

I want to measure the objects size in memory, how much this object takes & how much overhead it has , etc...

For example: We found that the normal System.String Class, it supports UNICODE, while we work only, so we can save 50% of the object size if we can use ASCII-only-support String class.

Actual String size is calculated as that following:
Size = 20 + (n/2)^4 Bytes
Where 20 is overhead, & n is the no of characters in the string.

One of my team got this by researching, but we can't find anything else about other types. so if you can help by providing a profiler or a reference on how to calculate the sizes it will be very appreciated.

Thank you for your time

Ok so it sounds like you have some kind of EDI / TP thing to build then...
while I do not have a system in the billions of lines of parsing I do have a working app that does a good volume of web services traffic that goes to a sql db.

my system has 2 servers, each is an "off the shelf" DELL server.
we run about 6-8k orders a day plus other related traffic (auth, void,inq and so on)
the "front end" web server runs the ws on one virtual and 2 other web apps on others.

I have never seen ram go over about 600 megs in use.

now I think you have a lot more string management then my app and it sounds like a higher number of Transactions per day.

I think I would build a "Mockup" of the main logic and run it and just see what happens to memory use over a good time span.

I hope this is not beeing to basic but you do know that .net uses a stratigey of allocating ram from the OS in advance in large blocks and not giing it back unless it has to right ??

so if you run a large app it can grab what looks like a huge amount of ram and hold it till the app shuts down.
inside it's moving stuff around and keeping from asking for more os memory till it has to.

any profiler should show you how active GC 0,1 are and what kind of objects are scavanged (strings, other types)
there are some documents and stuff on msdn about what kind of pattern you want to see but as I recall it's mostly GC0 with a few things living longer and not scavenged till the end.
stuff that just hits GC1 and then dies is the "Worst case" as I recall for the .Net GC system.

Remon wrote:



figuerres wrote:  now I think you have a lot more string management then my app and it sounds like a higher number of Transactions per day. I think I would build a "Mockup" of the main logic and run it and just see what happens to memory use over a good time span.

True. System stores tons of strings.
I have tried to parse about 150K lines. The system was initially 10 Megs, Expanded to about 160 Megs after parsing (Note: array of parsed objects exists into memory now).
Most properties are strings.

figuerres wrote:  I hope this is not beeing to basic but you do know that .net uses a stratigey of allocating ram from the OS in advance in large blocks and not giing it back unless it has to right ??

Actually no this is the first time to hear that. However, as i said above, the program got more memory while parsing (10M to 150 M)

figuerres wrote:  any profiler should show you how active GC 0,1 are and what kind of objects are scavanged (strings, other types) there are some documents and stuff on msdn about what kind of pattern you want to see but as I recall it's mostly GC0 with a few things living longer and not scavenged till the end. stuff that just hits GC1 and then dies is the "Worst case" as I recall for the .Net GC system.

can u recommend a profiler ?
also. can i have a string supports ASCII only ? & How ?

yeah, .net looks for a "working set" it will grow a process till it seems to have enoguh ram, depending on the runtime it uses different logic on GC events also....
see on a server it uses one set of dll's and on a client it uses a different set. clients tend to run 1 app and want max speed.
servers tend to need to balance things. also on a client it may not GC till the app closes if it can. on a server it will GC based on a "hartbeat" to keep multiple processes balanced.

I have not done any profiling in a while ...

you may want to look at:
http://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-8926-862b40aa0cd0&DisplayLang=en

also if you do have a lot of string stuff see if string builder helps.

if you are not aware of this it may make a huge difference:

in .Net strings are "IMUTEABLE" wich means that
string a

string b


for loop x 1,000
     a=i.tostring()
      b=b+","+a;

will create over 1,000 strings in memory that will need to be GC'ed

if you do:

a = b + a

then you are creating

a_old
a_new

each a different string, with  a refering to a_new and when a gc happens a_old can be droped if no other ref's point to it.

but if you have say

foo = a

a = b + a

then a_old can not be gc in all cases and may live till later.

StringBuilder

will allow you to work with a buffer and not create as many strings.

good use of that can reduce allocation presssure by huge amounts.

for example if you currently are not using it you may see something like:

old 10 meg - end at 160 megs
new 10 meg - end at 20 megs

just as a guess -  see what your code looks like and are you using strings where you can use string builder to cut back on allocating
100,000 or more temp-strings.

also a general rule I got from others and had been true is this:

write the app with good coding practice and then test it.
if you see a problem with perf or memory profile and find the problem.

in many cases 90% or more of the app's code will not matter.

you will find 1 to 5% of the code taking up 50% of the time or memory and you can then target that and tune it.

if you spend to much time trying to get too perfect you will actually waste a lot of time fixing code that was not a problem in the first place.

so let the tools tell you where to look.

just write good code in general and most of it will be just fine


also the size and memory is a moving target.

the Jit will make different code based on x86/ x64 and client or server and could change if there is a service pack that updates the Jitter.

so even if you find the size today on an x86 32 bit pc if you run it on an x64 bit server the size will be different !

Remon wrote:



figuerres wrote: StringBuilder will allow you to work with a buffer and not create as many strings. good use of that can reduce allocation presssure by huge amounts. for example if you currently are not using it you may see something like: old 10 meg - end at 160 megs new 10 meg - end at 20 megs just as a guess -  see what your code looks like and are you using strings where you can use string builder to cut back on allocating 100,000 or more temp-strings.

public void Parse(ref string Line)

{

int iAttributeCursor = 0, iAttributesCount;

string[] arrAttributes = Line.Split('\t');

//Get the Severity ( First Attribute of the Line )

_Priority = int.Parse(arrAttributes[iAttributeCursor++]);

//Get the Facility by Shifting the Priority right by 3 ( dividing by 8 )

_Facility = _Priority >> 3;

//Get the Severity by bitwise Anding with 7

//"3 ones in the least significant 3 bits" = getting the modulus of priority divided by 8

_Severity = _Priority & 7;

//Get the timestamp of the event ( Convert from Ticks )

_Timestamp = new DateTime(long.Parse(arrAttributes[iAttributeCursor++]));

//Get the device name which populated the event

_DeviceName = arrAttributes[iAttributeCursor++];
}

that's a sample for the code i ve written.
StringBuilder won't do good, because it's not FEW large strings, they are LOTS of SHORT strings.
I have tried somthing like: _DeviceName = (string)arrAttributes[iAttributeCursor++].Clone();  just to make sure the the arrAttributes will be GCed.

but this haven't made any difference & it will affect the speed of the system (boxing & unboxing)

I will try writing a string class based over bytes (supports ASCII only), got any ideas ?

My Take on this as of now is this:

you are getting a "string" of ASCII bytes that have text you need to "convert" yes?

then read the data as a stream with the ASCII encoding first.

then you can process the data as an array of bytes.

if you can read a "full buffer" of data
for example if a LINE ends with a know value like CR + LF
then write a method that scans the array for TAB and CR
and like the other post you can parse a set of bytes into an int w/o a string at all , when you get a datetime you can I think handle that sveral ways....
one of them in an inline convert

look at this for a starter:
http://www.chilkatsoft.com/faq/DotNetStrToBytes.html
and this:
http://msdn2.microsoft.com/en-us/library/system.text.asciiencoding.getstring.aspx

so you can do stuff like:
fooDate = new DateTime.Parse( enc.GetString(ByteArr,x,y));
which given the right x,y values should parse the datetime to the datetime variable w/o creating a "real" string in the middle as .net will see the result and inline the methods.

note that full optimization of this will not showup in debug!

the debug holds back some things so that the human can follow the code they wrote.

with a stream and byte array you should be able to have almost no strings to GC 

BTW:  this "looks like" a UNIX syslog -- or very close to that.

is that what you are parsing ??