Hey All,
been getting alot of CLR exceptions and out of memory exceptions on certain
machines. We have an old-school programmer on the team who still just can't
get OOP and as a result we have some LARGE code files and routines. The .net
framework documentation states...
"The common language runtime can throw the exception when memory is not
adequate to allocate for internal purposes or new managed objects. To avoid
the exception, avoid programming large methods that consume 64 or more
kilobytes of memory."
Does hit mean 64K big method (as in copy and paste the method to
notepad...save it and figure out how big it is??)
Thanks in advance
-dec
Jay B. Harlow [MVP - Outlook] - 21 Oct 2003 04:25 GMT
dec,
> Does hit mean 64K big method (as in copy and paste the method to
> notepad...save it and figure out how big it is??)
I would think it means the size of the method after it was compiled into IL.
After the "old-school programmer" has had the proverbial "Aha!" on how to
apply OOP techniques to his programming, you may want to introduce
Refactoring, as Refactoring is a technique to restructure code in a
disciplined way, including breaking apart large monolithic methods into OOP
friendly objects & methods. For details see http://www.refactoring.com
Hope this helps
Jay
> Hey All,
> been getting alot of CLR exceptions and out of memory exceptions on certain
[quoted text clipped - 12 lines]
> Thanks in advance
> -dec
decrypted - 22 Oct 2003 19:09 GMT
I have been refactoring this code since I started working here. However,
with 300,000 lines of spegety spanning 170 windows and having the
responsibilities of my day to day work, its a tough battle.
-dec
> dec,
> > Does hit mean 64K big method (as in copy and paste the method to
[quoted text clipped - 30 lines]
> > Thanks in advance
> > -dec
Jay B. Harlow [MVP - Outlook] - 22 Oct 2003 21:29 GMT
Dec,
Sounds like one of my earlier jobs ;-)
Good Luck!
Jay
> I have been refactoring this code since I started working here. However,
> with 300,000 lines of spegety spanning 170 windows and having the
[quoted text clipped - 38 lines]
> > > Thanks in advance
> > > -dec
decrypted - 22 Oct 2003 22:57 GMT
hu?
> Dec,
> Sounds like one of my earlier jobs ;-)
[quoted text clipped - 51 lines]
> > > > Thanks in advance
> > > > -dec
Ori Gershony [MSFT] - 27 Oct 2003 18:51 GMT
The main problem with large methods is that the just in time compiler does
not scale well (with respect to perf) when you increase the number of basic
blocks. When you run into this, you will notice that the large methods
take a long time to JIT. The best metric to evaluate the size of a method
is the number of basic blocks it contains.
In your case, the most likely explanation is that you are just using too
much memory for your objects (most likely you are leaking memory by not
release all references to objects that you are not using anymore). There
are performance counters that help you track the memory usage of the GC
heap. You can also use the .Net Profiler to better understand the objects
allocated by your program.
Good luck!
-- Ori.
--------------------
>From: "decrypted" <decrypted@earthlink.net>
>Subject: Out Of Memory Exceptions
[quoted text clipped - 8 lines]
>NNTP-Posting-Host: bdsl.66.14.114.147.gte.net 66.14.114.147
>Path:
cpmsftngxa06.phx.gbl!cpmsftngxa09.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.
phx.gbl
>Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.clr:8381
>X-Tomcat-NG: microsoft.public.dotnet.framework.clr
[quoted text clipped - 15 lines]
>Thanks in advance
>-dec

Signature
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Note: For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
originated.