To find out exactly how much memory you are actually using you can run a quick
GC.Collect(). With the 140 megs, what you are most likely seeing, is a bunch of
objects sitting around that were part of the import process, but aren't part of
your
memory footprint that are actually being used.
Note that moving forward and creating new objects within your application will
be
a little slower at first because your application will have to reallocate all of
the pages
of memory that were deallocated during the GC process. If you don't plan on
creating
a large number of objects then this won't be a large issue. If you do plan on
doing a
lot of work, then eventually you'll re-use that 140 megs of memory, so don't
even bother
with the GC collection.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog:
http://weblogs.asp.net/justin_rogers
"Derrick" <de*********@excite.com> wrote in message
news:OC*************@TK2MSFTNGP11.phx.gbl...
Thanks to many on this newsgroup, I now have a prototype Windows Forms C#
app that reads xml documents into DataSets via XmlDataDocument, and does
*stuff* with it.
I basically have about 25 megs worth of xml data that I read in and operate
on. Once loaded, before doing anything of substance with the data, my app's
memory footprint goes up to nearly 140 megs right off the bat.
Question is, if this is not an expected observation, what should I look at,
in general, to cut down the footprint closer to the size of loaded files?
Thanks in advance!
Derrick
