Hi David,

but why can I see memory decreases if I allocate and free memory with new/delete on my own?

The performance of the sarvega benchmark test with the heavily used "xsl:strip-space/xsl:preserve-space" was increased by factor 3. Good work! (but it remains at the half of the performance of saxon or xt ;^) Maybe I am able to do some more profiling on this testcase, but I do not know how many people in the real world using these features...

Thanks,

HolgeR

[EMAIL PROTECTED] schrieb:

Hi HolgeR,

That's probably an issue with the C runtime libraries memory allocation
strategy.  Often, allocators will not immediately free all memory, keeping
some around for future allocations, making them much faster.  The drawback
is what you are seeing -- the memory usage of the process does not
decrease.

By the way, I made some major changes in Xalan 1.8 to fix the
xsl:strip-space/xsl:preserve-space performance problem you reported.  If
you have a chance to test it, that would be great.

Thanks!

Dave



|---------+--------------------------->
|         |           Holger Fl�rke   |
|         |           <[EMAIL PROTECTED]|
|         |           ic.de>          |
|         |                           |
|         |           05/26/2004 12:14|
|         |           AM              |
|         |           Please respond  |
|         |           to xalan-c-users|
|---------+--------------------------->
  
>--------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                                         |
  |        To:      [email protected]                                
                                                         |
  |        cc:      (bcc: David N Bertoni/Cambridge/IBM)                        
                                                         |
  |        Subject: Re: Memory Leak in Xalan-C 1.7?                             
                                                         |
  
>--------------------------------------------------------------------------------------------------------------------------------------|



I have some more information about this topic. This behaviour could be
observed on Xalan-C 1.8 (unmodified) and Xerces-C 2.5 (unmodified) on
SuSE9.1, too. The good news: It is not a memory leak.

If I destroy each stylesheet after one compile/transform run, the memory
will not grow. I think this behavior can be explained by some preallocated
(and reused) memory within Xalan. But how I get rid of this memory? The
destruction of XalanTransformer, even a terminate of the whole library does

not seem to work.

HolgeR

Holger Fl�rke schrieb:


Hi there,

 I have tried to compile multiple Stylesheets, store the pointers to
the compiled stylesheets within a stl list, do some transformations, and
destroy the stylesheets one after another. After each stylesheet
compilation and after each stylesheet destruction, I glimpsed into
/proc/self/statm, the memory usage of the current process on linux
machines. I was wondering why the memory usage stays at a high level
even after the destruction of the compiled stylesheets and the
termination of the library.

Is there anywhere a memory leak with the usage of multiple compiled
stylesheets? Or am I wrong with my interpretation of the memory usage of
the process? Does anybody see the same results?

I have attached the source of the test, a modified version of the
compiled stylesheet example. It does only run on linux machines. You
have to put the foo*-files from the compiled stylesheet sample within
the same directory. I used this on RedHat WS3.0 with "gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-24)", Xalan-C 1.7 (slightly modifed) and
Xerces-C 2.4 (slightly modifed). My results are:
Start
821 821 763 4 813 4 58
compiled Stylesheet #0
1140 1140 1052 4 1102 34 88
compiled Stylesheet #1
1150 1150 1052 4 1102 44 98
compiled Stylesheet #2
1157 1157 1052 4 1102 51 105
compiled Stylesheet #3
1166 1166 1052 4 1102 60 114
compiled Stylesheet #4
1173 1173 1052 4 1102 67 121
compiled Stylesheet #5
1180 1180 1052 4 1102 74 128
compiled Stylesheet #6
1186 1186 1052 4 1102 80 134
compiled Stylesheet #7
1192 1192 1052 4 1102 86 140
compiled Stylesheet #8
1199 1199 1052 4 1102 93 147
compiled Stylesheet #9
1206 1206 1052 4 1102 100 154
...
destroying Stylesheet
1262 1262 1100 4 1150 108 162
destroying Stylesheet
1262 1262 1100 4 1150 108 162
destroying Stylesheet
1262 1262 1100 4 1150 108 162
destroying Stylesheet
1262 1262 1100 4 1150 108 162
destroying Stylesheet
1262 1262 1100 4 1150 108 162
destroying Stylesheet
1262 1262 1100 4 1150 108 162
destroying Stylesheet
1262 1262 1100 4 1150 108 162
destroying Stylesheet
1262 1262 1100 4 1150 108 162
destroying Stylesheet
1262 1262 1100 4 1150 108 162
destroying Stylesheet
1262 1262 1100 4 1150 108 162
Xalan terminated
1264 1264 1102 4 1152 108 162
Xerces terminated
1266 1266 1104 4 1154 108 162
End

Regards,

HolgeR


--
holger floerke                      d  o  c  t  r  o  n  i  c
email [EMAIL PROTECTED]          information publishing + retrieval
phone +49 2222 9292 90              http://www.doctronic.de




-- holger floerke d o c t r o n i c email [EMAIL PROTECTED] information publishing + retrieval phone +49 2222 9292 90 http://www.doctronic.de

Reply via email to