xml web service proxy and serializable assembly generation

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

The POS application we are developing is designed to call two web services.
The first web service has only one method and it returns a string with an Uri
where the second web service is located. The second web service has several
methods and objects. One of the methods is used to download the data for the
particular POS location (terminal). This data is parsed and a SqlCe database
is created on the device. The data downloaded is not that large, worst case
scenario it is 400KB.



After profiling the PC version of the application is shows that it is
allocating a total of 50MB of process global heap memory and the working set
of the application is about 4 to 5 MB. The same behavior happens on the
Pocket PC version of the application.



The problem I am having is that on the Pocket PC there is not enough memory.
An OutOfMemoryExeption is thrown. The Pocket PC has about 32MB of Program
memory and about 7 MB of storage memory. I have taken the following steps
towards finding a solution to this problem.



I have minimized and optimized the usage of memory.


I monitor System memory and when it reaches a threshold I call GC.Collect.




I handle the WM_Hibernate message and call GC.Collect and dispose some
unmanaged resources.


After profiling the application some more I found out that if the
application goes to the background the OS reclaims unused memory by the
process. So after this discovery I added code to minimize the application
when the memory starts to get low. This helped a little but still run out of
memory.




I have also attempted to control the distribution of storage and program
memory.


I proceeded to profile the application again and realized that the creation
and invocation of a web service call creates about allocates about 11MB to
16MB of memory. I profiled the application of the PC and the same occurs.
It turns out that the .Net FX reflects all types in a web service proxy and
generates a serializable assembly for each proxy. To do this it loads
Jscript runtime dll and the Vsa runtime dll.




After the above observation I tried to pre-generate the serializable
assemblies using a tool called sgen.exe and profile the application again but
it seems that it does not load the serializable assemblies at all it
generates them. Everything I have read about this approach should work but
apparently I must be missing something.


After analyzing these findings I think that if I avoid the 16MB hit of the
serializable assemblies generation the application will load since the
initial working set of the application is 4 to 5 MB.
 
The XmlSerializer class creates a temporary assembly for each type that
it serializes. Usually, this temporary assembly is cached, so the
performance hit is only taken the first time a particular type is
serialized. Here's the catch:

http://dotnetjunkies.com/WebLog/josephcooney/archive/2003/10/21/2760.aspx


"...if you use one of the overloads for the XmlSerializer constructor
other than the one that just accepts a type you create a new temporary
assembly each time you create a new serializer. If you want to use
these constructors either pay the performance penalty, or don't create
a new one each time."

If you're using one of these overloaded constructors, it will ignore
the pre-compiled assemblies that you created with sgen.exe and re-build
them each time.
 
Back
Top