| Groups | Blog | Home |
dotnet performance : C# System.String Memory Usage
I have created a service which parses real-time prices from one format into another. This is all working very quickly and nicely, however, I have recently found that the memory usage is astronomical after a few hours. (1.5-2 Gig) After a good amount of digging I found that the memory usage is is all in System.String and contained within the pricing object. This object makes extensive use of a single string object which is passed as an OUT parameter to a Interop (unmanaged) object. There are approximately 30 calls to the unmanaged interop object within the class, and the class is called upwards of 3-4 times per second. I know that System.Strings are immutable, therefore, I am assuming that each time this call returns within the class, a new String object is being created and allocated. The issue is that many of these objects are being promoted to Gen2 and never being finalized/destroyed by the GC. The GC apparently assumes that all these string objects are still alive and will not remove them. I think that this is due to the frequency at which these objects are being created. Unfortunately I cannot mitigate the impact using StringBuilder, as the parameters are OUT string on the interop assembly (this could be changed by my colleague who wrote it, if neccesary.) Anyway, does anyone have any idea how to get the memory usage down to a manageable level? Kind Regards, Mike
[quoted text, click to view]
<mwhalber@gmail.com> wrote in message news:1165579492.712295.93700@n67g2000cwd.googlegroups.com... > Hi, > > I have created a service which parses real-time prices from one format > into another. This is all working very quickly and nicely, however, I > have recently found that the memory usage is astronomical after a few > hours. (1.5-2 Gig) > > After a good amount of digging I found that the memory usage is is all > in System.String and contained within the pricing object. This object > makes extensive use of a single string object which is passed as an OUT > parameter to a Interop (unmanaged) object. > > There are approximately 30 calls to the unmanaged interop object within > the class, and the class is called upwards of 3-4 times per second. I > know that System.Strings are immutable, therefore, I am assuming that > each time this call returns within the class, a new String object is > being created and allocated. The issue is that many of these objects > are being promoted to Gen2 and never being finalized/destroyed by the > GC. The GC apparently assumes that all these string objects are still > alive and will not remove them. I think that this is due to the > frequency at which these objects are being created. > > Unfortunately I cannot mitigate the impact using StringBuilder, as the > parameters are OUT string on the interop assembly (this could be > changed by my colleague who wrote it, if neccesary.) > > Anyway, does anyone have any idea how to get the memory usage down to a > manageable level? Are you sure you can't use StringBuilder on an out parameter? I'm pretty sure I've used it with P/Invoke. John
The unmanaged assembly defines the out parameter as a string when the
interop is created. I could use p/invoke in order to pass a stringbuilder to the function, however, the assmbly does some work on an object that is created initially...like so: class ManagedClass { public ManagedClass() { UnmanagedClass myUnmanagedClass = new UnmanagedClass(); myUnmanagedClass.DoSomething(); //this manipulates the instance of the class string myString = "EMPTY"; myUnmanagedClass.DoSomethingElse( out myString); //this line is executed about 30 times per instantiation of this class, //each time creating a new string, as this is an out param and strings are immutable } This is why I don't think I can use p/invoke, as ther is work done on the instance of the class created from the interop assmbly. Thanks very much for any help! Mike On Dec 8, 4:11 pm, "John Saunders" <john.saunders at trizetto.com> [quoted text, click to view] wrote:
> <mwhal...@gmail.com> wrote in messagenews:1165579492.712295.93700@n67g2000cwd.googlegroups.com... > > > > > Hi, > > > I have created a service which parses real-time prices from one format > > into another. This is all working very quickly and nicely, however, I > > have recently found that the memory usage is astronomical after a few > > hours. (1.5-2 Gig) > > > After a good amount of digging I found that the memory usage is is all > > in System.String and contained within the pricing object. This object > > makes extensive use of a single string object which is passed as an OUT > > parameter to a Interop (unmanaged) object. > > > There are approximately 30 calls to the unmanaged interop object within > > the class, and the class is called upwards of 3-4 times per second. I > > know that System.Strings are immutable, therefore, I am assuming that > > each time this call returns within the class, a new String object is > > being created and allocated. The issue is that many of these objects > > are being promoted to Gen2 and never being finalized/destroyed by the > > GC. The GC apparently assumes that all these string objects are still > > alive and will not remove them. I think that this is due to the > > frequency at which these objects are being created. > > > Unfortunately I cannot mitigate the impact using StringBuilder, as the > > parameters are OUT string on the interop assembly (this could be > > changed by my colleague who wrote it, if neccesary.) > > > Anyway, does anyone have any idea how to get the memory usage down to a > > manageable level?Are you sure you can't use StringBuilder on an out parameter? I'm pretty > sure I've used it with P/Invoke. > > John
have you tried forcing a GC.Collect(2) just to see if it makes a difference?
If so, why not do that on a timer... say, every 15 minutes? Thanks, Shawn
[quoted text, click to view]
> calling GC.Collect is not a good solution. The .NET Framework calls those > methods when necessary, calling it manually will hardly do anything useful > (but some bad things...). While this might be true (in general) I have a project that actually improves scalability and performance by calling GC.Collect at the right place. Without doing so, we can only get about N number of connections (TCP/IP) on a single server. By doing so, we get about N*5 without a single noticeable degradation of performance. There's also another place where we have lots of string handling where placing a GC.Collect in the right place drastically increases our perceivable performance. But I agree with you, in general, there probly is a better way. But that doesn't mean to rule out the possibility. Just because everyone says not to, doesn't mean you shouldn't see for yourself whether doing so might help your situation. Of course, this also assumes you understand more about the GC/JIT/CLR internals than most others do. It also asummes you are a master of profiling so you can determine whether it helps or not. YMMV. Thanks, Shawn
Hello,
calling GC.Collect is not a good solution. The .NET Framework calls those methods when necessary, calling it manually will hardly do anything useful (but some bad things...). One approach here is to look if the strings are being referenced by another object. The SciTech memory profiler is a good start here. Best regards, Henning Krause [quoted text, click to view] "Shawn B." <leabre@html.com> wrote in message
news:eEmqQ0UHHHA.2112@TK2MSFTNGP03.phx.gbl... > have you tried forcing a GC.Collect(2) just to see if it makes a > difference? If so, why not do that on a timer... say, every 15 minutes? > > > Thanks, > Shawn > >
Hi Shawn,
If you're getting 5x the TCPIP performance by calling GC.Collect, you're suffering very badly from heap fragmentation due to all the pinning that's going on when you send/receive data. GC.Collect isn't really the right answer there, although I understand how it could look that way. What you really need is a buffer pool that's all allocated together, and that you check byte[] buffers into and out of. This way you don't allocate new byte[] each time you make a socket call - this causes continual fragmentation, and you'll eventually run out of memory. The problem is described in detail here: https://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx A good pair of articles on the subject is here: http://www.coversant.net/dotnetnuke/Default.aspx?tabid=88&EntryID=9 http://blogs.msdn.com/adarshk/archive/2005/08/20/454022.aspx .... and the limits of how far you can go is talked about here: http://www.coversant.net/Default.aspx?tabid=88&EntryID=10 In short (re: your original assertion) the only time you really want to call "GC.Collect" is just before you're forced to grow your buffer pool. When you do grow, you want to grow by a large amount (1k, 5k, 10k instances of whatever your buffer size is) so that any holes in your heap are all close together. This leverages the GC.Collect mostly to compact the heap, so that your buffers are allocated as low as possible. -- Chris Mullins, MCSD.NET, MCPD:Enterprise http://www.coversant.net/blogs/cmullins [quoted text, click to view] "Shawn B." <leabre@html.com> wrote in message news:u8HogwtIHHA.2456@TK2MSFTNGP06.phx.gbl... >> calling GC.Collect is not a good solution. The .NET Framework calls those >> methods when necessary, calling it manually will hardly do anything >> useful (but some bad things...). > > While this might be true (in general) I have a project that actually > improves scalability and performance by calling GC.Collect at the right > place. Without doing so, we can only get about N number of connections > (TCP/IP) on a single server. By doing so, we get about N*5 without a > single noticeable degradation of performance. There's also another place > where we have lots of string handling where placing a GC.Collect in the > right place drastically increases our perceivable performance. > > But I agree with you, in general, there probly is a better way. But that > doesn't mean to rule out the possibility. Just because everyone says not > to, doesn't mean you shouldn't see for yourself whether doing so might > help your situation. Of course, this also assumes you understand more > about the GC/JIT/CLR internals than most others do. It also asummes you > are a master of profiling so you can determine whether it helps or not. > > YMMV. > > > Thanks, > Shawn >
Thanks Chris.
Thanks, Shawn [quoted text, click to view] "Chris Mullins" <cmullins@yahoo.com> wrote in message news:%230k8UHwIHHA.3872@TK2MSFTNGP06.phx.gbl... > Hi Shawn, > > If you're getting 5x the TCPIP performance by calling GC.Collect, you're > suffering very badly from heap fragmentation due to all the pinning that's > going on when you send/receive data. > > GC.Collect isn't really the right answer there, although I understand how > it could look that way. What you really need is a buffer pool that's all > allocated together, and that you check byte[] buffers into and out of. > This way you don't allocate new byte[] each time you make a socket call - > this causes continual fragmentation, and you'll eventually run out of > memory. > > The problem is described in detail here: > https://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx > > A good pair of articles on the subject is here: > http://www.coversant.net/dotnetnuke/Default.aspx?tabid=88&EntryID=9 > http://blogs.msdn.com/adarshk/archive/2005/08/20/454022.aspx > > ... and the limits of how far you can go is talked about here: > http://www.coversant.net/Default.aspx?tabid=88&EntryID=10 > > In short (re: your original assertion) the only time you really want to > call "GC.Collect" is just before you're forced to grow your buffer pool. > When you do grow, you want to grow by a large amount (1k, 5k, 10k > instances of whatever your buffer size is) so that any holes in your heap > are all close together. This leverages the GC.Collect mostly to compact > the heap, so that your buffers are allocated as low as possible. > > -- > Chris Mullins, MCSD.NET, MCPD:Enterprise > http://www.coversant.net/blogs/cmullins > > > "Shawn B." <leabre@html.com> wrote in message > news:u8HogwtIHHA.2456@TK2MSFTNGP06.phx.gbl... >>> calling GC.Collect is not a good solution. The .NET Framework calls >>> those methods when necessary, calling it manually will hardly do >>> anything useful (but some bad things...). >> >> While this might be true (in general) I have a project that actually >> improves scalability and performance by calling GC.Collect at the right >> place. Without doing so, we can only get about N number of connections >> (TCP/IP) on a single server. By doing so, we get about N*5 without a >> single noticeable degradation of performance. There's also another place >> where we have lots of string handling where placing a GC.Collect in the >> right place drastically increases our perceivable performance. >> >> But I agree with you, in general, there probly is a better way. But that >> doesn't mean to rule out the possibility. Just because everyone says not >> to, doesn't mean you shouldn't see for yourself whether doing so might >> help your situation. Of course, this also assumes you understand more >> about the GC/JIT/CLR internals than most others do. It also asummes you >> are a master of profiling so you can determine whether it helps or not. >> >> YMMV. >> >> >> Thanks, >> Shawn >> > >
You're right - StringBuilder is the way to get [out] string values. I think
it's fair to say that every [out] string item on pinvoke.net uses StringBuilder for the returned string. -- Phil Wilson [Microsoft MVP Windows Installer] [quoted text, click to view] "John Saunders" <john.saunders at trizetto.com> wrote in message news:eBO7$NuGHHA.4440@TK2MSFTNGP03.phx.gbl... > <mwhalber@gmail.com> wrote in message > news:1165579492.712295.93700@n67g2000cwd.googlegroups.com... >> Hi, >> >> I have created a service which parses real-time prices from one format >> into another. This is all working very quickly and nicely, however, I >> have recently found that the memory usage is astronomical after a few >> hours. (1.5-2 Gig) >> >> After a good amount of digging I found that the memory usage is is all >> in System.String and contained within the pricing object. This object >> makes extensive use of a single string object which is passed as an OUT >> parameter to a Interop (unmanaged) object. >> >> There are approximately 30 calls to the unmanaged interop object within >> the class, and the class is called upwards of 3-4 times per second. I >> know that System.Strings are immutable, therefore, I am assuming that >> each time this call returns within the class, a new String object is >> being created and allocated. The issue is that many of these objects >> are being promoted to Gen2 and never being finalized/destroyed by the >> GC. The GC apparently assumes that all these string objects are still >> alive and will not remove them. I think that this is due to the >> frequency at which these objects are being created. >> >> Unfortunately I cannot mitigate the impact using StringBuilder, as the >> parameters are OUT string on the interop assembly (this could be >> changed by my colleague who wrote it, if neccesary.) >> >> Anyway, does anyone have any idea how to get the memory usage down to a >> manageable level? > > Are you sure you can't use StringBuilder on an out parameter? I'm pretty > sure I've used it with P/Invoke. > > John > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |