Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Remote Application Platform (RAP) » Reducing RAP memory consumption (serverside / per session)
Reducing RAP memory consumption (serverside / per session) [message #96916] Fri, 04 July 2008 12:57 Go to next message
Stefan Hansel is currently offline Stefan Hansel
Messages: 103
Registered: July 2009
Senior Member
<br><font size=2 face="sans-serif">Are there any ideas or plans to tune
RAP memory consumption for each RAP-session ?</font>
<br>
<br><font size=2 face="sans-serif">I did some tests with a simple GUI (1x
Shell, 50 Labels, 50 Textareas, 1 Button) with a RAP-Standalone-Webapp
(no Workbench, no equinox used).</font>
<br><font size=2 face="sans-serif">The result are not too amazing - 2000
concurrent users/session swallow aprrox. 750MB of Heap in this simple scenario
(*shiver*).</font>
<br>
<br><font size=2 face="sans-serif">When analyzing the HEAP it turns out,
that (as expected) most of the widgets (in this case Label-texts) take
that memory.</font>
<br>
<br><font size=2 face="sans-serif">Following ideas came into my mind:</font>
<br>
<br><font size=2 face="sans-serif">1) Most of the stateful data could be
put into the session itself. Thus a servlet-container could serialize the
session and have some more headroom left when more users come into play.</font>
<br><font size=2 face="sans-serif">On the long run, this would just be
just a little improvement in my opinion.</font>
<br>
<br>
<br><font size=2 face="sans-serif">2) I'm aware that RAP is very stateful
- but in 99% of the time Label-texts are only set, never read.</font>
<br><font size=2 face="sans-serif">So when the request is answered to the
browser all label-texts could be nulled, because qooxdoo then shows the
labels and would only be interested in textchanges (which could only be
triggered by a new 'setText').</font>
<br>
<br><font size=2 face="sans-serif">Looking at the code of a label the text
(if not requested by the getter) is only used for size-calculations (which
eventually take place in later requests due to relayouting). But just calculating
and caching the size when the text is set would be far more memory friendly
then saving the Label-text all the time.</font>
<br>
<br><font size=2 face="sans-serif">Of course - to be fully backward-compatible
such a memory-saving mode had to be optional (in the worst case to be specified
for each label). There might be some cases, when an application wants to
read its own Label-texts.</font>
<br>
<br><font size=2 face="sans-serif">A similar optimization could be done
with TableItemDatas I assume. Actually the application holds the TableModel
in memory so there is no need to keep all the texts of each cell in memory.</font>
<br>
<br>
<br><font size=2 face="sans-serif">What do you think ? Do those optimizations
sound reasonable to you, would it make sense to dig deeper into this ?
At least for me it sounds as if up to 50% of the session-state could be
eliminated this way.</font>
<br><font size=2 face="sans-serif">Or do you expect problems because Label-texts
are read more (in later requests) than I might think ?</font>
<br><font size=2 face="sans-serif">Are there other ideas to face the problem
?</font>
<br>
<br><font size=2 face="sans-serif">How do other people work around the
memory issue ? I'm pretty amazed that RAP-applications are run on the internet
(Yoxos, RAP-Demos) instead of just intranets, where the user-count is limited
? </font>
Re: Reducing RAP memory consumption (serverside / per session) [message #97115 is a reply to message #96916] Sun, 06 July 2008 17:15 Go to previous messageGo to next message
Stefan Hansel is currently offline Stefan Hansel
Messages: 103
Registered: July 2009
Senior Member
<br><font size=2 face="sans-serif">Ooops. </font>
<br><font size=2 face="sans-serif">I'm very sorry but just realized, that
I posted wrong statistics.</font>
<br>
<br><font size=2 face="sans-serif">Corrected: Tests where done with a composite
containing 200 Label- + 200 (empty) Text-Widgets * 2000 sessions. (not
50Labels/Texts as stated in the previous post).</font>
<br><font size=2 face="sans-serif">The heap grows up to 740MB (measured
by just dumping the heap).</font>
<br>
<br><font size=2 face="sans-serif">Anyway - I did some further heap investigations
and I have to correct my suggestions a bit: </font>
<br><font size=2 face="sans-serif">If Labels-texts are not generated, then
they are not consuming that much heap, because the same String is referenced
by all sessions.</font>
<br>
<br><font size=2 face="sans-serif">I found 2 other memory consumers instead:</font>
<br><font size=2 face="sans-serif">WidgetAdapter (which holds a 'preservedValue'-HashMap
which seems to be only needed while processing requests, but not for 'idle'-sessions)</font>
<br><font size=2 face="sans-serif">EventAdapter (which is actually written
to save memory in its 'listenerSets' - but since every Widget gets at least
a DisposeListener, it needs memory for every widget though).</font>
<br>
<br><font size=2 face="sans-serif">When optimizing this (can provide patches
later after some more testing) I was able to drop memory-consumption of
the same app to 450MB for 2000 open sessions.</font>
<br>
<br><font size=2 face="sans-serif">Still leaves the question, if you think
</font>
<br><font size=2 face="sans-serif">1) that TableItem$Data's could be cleared
after rendering if an app doesn't need read-access on them (which helped
apps which are quite stateless and keep only refrences to object-ids after
creating a table)</font>
<br><font size=2 face="sans-serif">2) that Label.text could be cleared
after rendering if an app doesn't need read-access on them (which helped
apps with generated labels)</font>
<br>
Re: Reducing RAP memory consumption (serverside / per session) [message #97278 is a reply to message #97115] Tue, 08 July 2008 06:42 Go to previous messageGo to next message
Eclipse User
Originally posted by: rherrmann.innoopract.com

Hi Stefan,

thanks for your input. As a general note, RAP aims to bring the -
what we believe powerful - Eclipse programming model to the web.
Thus it is server-centric and stateful with all its pros and cons.

Please also see my comments below.

Cheers,
Rüdiger

stefan.hansel@tolina.de wrote:
>
> Ooops.
> I'm very sorry but just realized, that I posted wrong statistics.
>
> Corrected: Tests where done with a composite containing 200 Label- + 200
> (empty) Text-Widgets * 2000 sessions. (not 50Labels/Texts as stated in
> the previous post).
> The heap grows up to 740MB (measured by just dumping the heap).
Could you provide more details on what methods and tools these
numbers are based?

From your numbers, it is not clear what increase in memory the 2000
sessions caused. Under the assumption that the entire 740MB are
consumed by the 2000 sessions, this would result in 0.37MB per session.

>
> Anyway - I did some further heap investigations and I have to correct my
> suggestions a bit:
> If Labels-texts are not generated, then they are not consuming that much
> heap, because the same String is referenced by all sessions.
I think, generated label texts are closes to a real-world scenario.
An application would probably read strings from a localized
properties file or similar and thus consume more memory that the
interned literal or constant strings.

>
> I found 2 other memory consumers instead:
> WidgetAdapter (which holds a 'preservedValue'-HashMap which seems to be
> only needed while processing requests, but not for 'idle'-sessions)
After processing a request, the preservedValues map is cleared with
Map#clear(). This could be changed to discard of the map
(preservedValues = null) if it is proven that the there is a
considerable benefit in memory consumption. On the other hand, this
might have a performance impact when re-creating the map and all its
entries with every request.

> EventAdapter (which is actually written to save memory in its
> 'listenerSets' - but since every Widget gets at least a DisposeListener,
> it needs memory for every widget though).
Just to clarify, the EventAdapter wasn't written to save memory.
Only the ListenerSet, which does not allocate more memory than
necessary to hold all elements.

>
> When optimizing this (can provide patches later after some more testing)
> I was able to drop memory-consumption of the same app to 450MB for 2000
> open sessions.
You are welcome. Please file a bug to attach the patches to.

>
> Still leaves the question, if you think
> 1) that TableItem$Data's could be cleared after rendering if an app
> doesn't need read-access on them (which helped apps which are quite
> stateless and keep only refrences to object-ids after creating a table)
> 2) that Label.text could be cleared after rendering if an app doesn't
> need read-access on them (which helped apps with generated labels)
From a technical point of view, apart from very rare cases I don't
see a chance to partly discard a widgets state.
Depending on the parents layout, a widgets text is needed for
re-layouting (e.g. after one of its parents was resized) and for
text size requests.
Moreover from my point of view, programming against such
half-stateful widgets would be very error-prone. The programmer
would have to keep things in mind (e.g. are we serving the first
request?) that aren't obvious from reading the code. The widget
would reveal implementation details to its clients.
Re: Reducing RAP memory consumption (serverside / per session) [message #97325 is a reply to message #97278] Tue, 08 July 2008 13:55 Go to previous messageGo to next message
Stefan Hansel is currently offline Stefan Hansel
Messages: 103
Registered: July 2009
Senior Member
<br><tt><font size=2>Hi Rüdiger, </font></tt>
<br>
<br><tt><font size=2>&gt;&gt; Thus it is server-centric and stateful with
all its pros and cons.</font></tt>
<br><tt><font size=2>Nevertheless can be tuned a lot, under some conditions
which should not be too difficult to adhere to (I hope) ;-)</font></tt>
<br>
<br><tt><font size=2>&gt;&gt; From your numbers, it is not clear what increase
in memory the 2000 <br>
&gt;&gt; sessions caused. Under the assumption that the entire 740MB are
<br>
&gt;&gt; consumed by the 2000 sessions, this would result in 0.37MB per
session.</font></tt>
<br>
<br><tt><font size=2>Indeed - quite a lot :D, but nevertheless your guess
is true.</font></tt>
<br><tt><font size=2>Here you'll have an export from SAP-Memory-Analyzer.
(For a definition of 'retained Heap' see </font></tt><a href=http://jazoon.com/download/presentations/2160.pdf><tt><font size=2>http://jazoon.com/download/presentations/2160.pdf</font></tt></a><tt><font size=2>
, slide 18)</font></tt>
<br><tt><font size=2>As you can see 400.000 Text's and Label's (200 * 2000
sessions) take up most of the HEAP (60%).</font></tt>
<br><tt><font size=2>Another big consumer in my example is the use of JGoodies-(SWT-ported)-FormLayout
(using and tuning this is our problem - don't know how much a GridLayout
would take) all other controls don't make up that big percentage of the
heap.</font></tt>
<br>
<br><tt><font size=2>Class Name &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;| Objects | Shallow Heap | Retained Heap | Retained
Heap, % </font></tt>
<br><tt><font size=2> ------------------------------------------------------------ -------------------------------------------------- </font></tt>
<br><tt><font size=2>&lt;ROOT&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; 1 | &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;</font></tt>
<br><tt><font size=2>|- org.eclipse.swt.widgets.Composite &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; 4.000 | &nbsp; &nbsp;
&nbsp;448.000 | &nbsp; 705.792.016 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
95,44% </font></tt>
<br><tt><font size=2>| &nbsp;|- org.eclipse.swt.widgets.Text &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| 400.000 | &nbsp; 41.600.000
| &nbsp; 246.400.000 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 33,32% </font></tt>
<br><tt><font size=2>| &nbsp;|- org.eclipse.swt.widgets.Label &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | 406.000 | &nbsp; 38.976.000
| &nbsp; 240.272.016 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 32,49% </font></tt>
<br><tt><font size=2>| &nbsp;|- net.ffxml.swtforms.layout.FormLayout &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; 4.000 | &nbsp; &nbsp; &nbsp;256.000
| &nbsp; 207.728.000 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 28,09% </font></tt>
<br><tt><font size=2>| &nbsp;|- org.eclipse.swt.widgets.Composite &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; 2.000 | &nbsp; &nbsp; &nbsp;224000
| &nbsp; &nbsp; 4.256.000 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0,58%
</font></tt>
<br><tt><font size=2>| &nbsp;|- org.eclipse.swt.widgets.ControlHolder &nbsp;
&nbsp; &nbsp; &nbsp; | &nbsp; 4.000 | &nbsp; &nbsp; &nbsp; 64.000 | &nbsp;
&nbsp; 3.472.000 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0,47% </font></tt>
<br><tt><font size=2>| &nbsp;|- org.eclipse.swt.widgets.Button &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; 2.000 | &nbsp; &nbsp;
&nbsp;208.000 | &nbsp; &nbsp; 1.248.000 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;0,17% </font></tt>
<br><tt><font size=2>| &nbsp;|- org.eclipse.swt.internal.widgets.WidgetAdapter|
&nbsp; 4.000 | &nbsp; &nbsp; &nbsp;128.000 | &nbsp; &nbsp; 1.040.000 |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0,14% </font></tt>
<br><tt><font size=2>| &nbsp;|- org.eclipse.rwt.internal.events.EventAdapter
&nbsp;| &nbsp; 4.000 | &nbsp; &nbsp; &nbsp; 64.000 | &nbsp; &nbsp; &nbsp;
768.000 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0,10% </font></tt>
<br><tt><font size=2>| &nbsp;|- org.eclipse.swt.graphics.Rectangle &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; 4.000 | &nbsp; &nbsp; &nbsp;
96.000 | &nbsp; &nbsp; &nbsp; &nbsp;96.000 | &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;0,01% </font></tt>
<br><tt><font size=2>| &nbsp;'- org.eclipse.swt.widgets.Control$ControlAdapter|
&nbsp; 4.000 | &nbsp; &nbsp; &nbsp; 64.000 | &nbsp; &nbsp; &nbsp; &nbsp;64.000
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0,01% </font></tt>
<br><tt><font size=2> ------------------------------------------------------------ -------------------------------------------------- </font></tt>
<br>
<br><tt><font size=2>If you drill down further (e.g. Text), you see that
WidgetAdapter and EventAdapter take a lot of space for their </font></tt>
<br><tt><font size=2>empty (quite-empty for EventAdapter) HashMaps (140MB
- double this, because all Label's take the same size again).</font></tt>
<br><tt><font size=2>If you consider that most of the widgets will never
need an Eventlistener this is quite a lot.</font></tt>
<br>
<br><tt><font size=2>Class Name &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | Objects | Shallow Heap | Retained
Heap | Retained Heap, % </font></tt>
<br><tt><font size=2> ------------------------------------------------------------ ----------------------------------------------------- </font></tt>
<br><tt><font size=2>&lt;ROOT&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp;
1 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 | &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;</font></tt>
<br><tt><font size=2>|- org.eclipse.swt.widgets.Composite &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; 4.000 | &nbsp;
&nbsp; &nbsp;448.000 | &nbsp; 705.792.016 | &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; 95,44% </font></tt>
<br><tt><font size=2>| &nbsp;|- org.eclipse.swt.widgets.Text &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | 400.000 | &nbsp;
41.600.000 | &nbsp; 246.400.000 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 33,32%
</font></tt>
<br><tt><font size=2>| &nbsp;| &nbsp;|- org.eclipse.swt.internal.widgets.WidgetAdapter|
400.000 | &nbsp; 12.800.000 | &nbsp; 105.600.000 | &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; 14,28% </font></tt>
<br><tt><font size=2>| &nbsp;| &nbsp;| &nbsp;|- java.util.HashMap &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;| 400.000 | &nbsp; 16.000.000 | &nbsp; &nbsp;73.600.000 | &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;9,95% </font></tt>
<br><tt><font size=2>| &nbsp;| &nbsp;| &nbsp;'- java.lang.String &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; | 400.000 | &nbsp; &nbsp;9.600.000 | &nbsp; &nbsp;19.200.000 | &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;2,60% </font></tt>
<br><tt><font size=2>| &nbsp;| &nbsp;|- org.eclipse.rwt.internal.events.EventAdapter
&nbsp;| 400.000 | &nbsp; &nbsp;6.400.000 | &nbsp; &nbsp;76.800.000 | &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; 10,39% </font></tt>
<br><tt><font size=2>| &nbsp;| &nbsp;| &nbsp;'- java.util.HashMap &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;| 400.000 | &nbsp; 16.000.000 | &nbsp; &nbsp;70.400.000 | &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;9,52% </font></tt>
<br><tt><font size=2> ------------------------------------------------------------ ----------------------------------------------------- </font></tt>
<br>
<br><tt><font size=2>Note that in this example Label-Strings don't count
as Retained Heap for the Label, 'cause the strings are shared by all Label's.</font></tt>
<br><tt><font size=2>The String's you see in the stats above are the widgetIDs
held be the WidgetAdapter. These could be tuned as well (saved as a Long
as long as no custom widget-IDs are used). I'll provide a patch for that
too.</font></tt>
<br>
<br><tt><font size=2>&gt;&gt; On the other hand, this might have a performance
impact when re-creating the map and all its entries with every request.</font></tt>
<br><tt><font size=2>Not too much I suppose. Object Creation is really
fast with current VMs - 'ten machine instructions' for java 1.4 and 1.5
according to guru Brian Goetz in 'Java Concurrency In Practice' (p. 241).</font></tt>
<br>
<br><tt><font size=2>&gt;&gt; I think, generated label texts are closes
to a real-world scenario. </font></tt>
<br><tt><font size=2>So tuning would have a big benefit. As I said - this
should be optional and every developer would have to take care of the used
API. </font></tt>
<br><tt><font size=2>But projects who need to reduce memory/increase concurrent
sessions always have to except restrictions in the way they program/architect.
</font></tt>
<br><tt><font size=2>Some things always come with sacrifices and not beeing
able to ever call Label.getText() is not much I expect.</font></tt>
<br><tt><font size=2>Furthermore tools like Checkstyle or AspectJ can take
care of forbidden API-access so runtime problems are not to be expected
(if the appropiate tools are used).</font></tt>
<br>
<br><tt><font size=2>Of course I didn't try anything yet - of other SWT-API
does heavy use of getText than I can forget the idea.</font></tt>
<br>
<br><tt><font size=2>I'm aware that layouting issues are a place where
the text is needed - but caching the size of the text should be sufficient
and be far more memory friendly than holding the whole string.</font></tt>
<br>
<br>
<br><tt><font size=2>I'll provide the patches for widgetAdapter and EventAdapter
tomorrow ... leisure time calls :D ...</font></tt>
<br>
<br>
Re: Reducing RAP memory consumption (serverside / per session) [message #97370 is a reply to message #97325] Wed, 09 July 2008 07:55 Go to previous messageGo to next message
Stefan Hansel is currently offline Stefan Hansel
Messages: 103
Registered: July 2009
Senior Member
<br><font size=2 face="Courier New">Patches can be found here ... </font>
<br><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=240143"><font size=2 face="Courier New">https://bugs.eclipse.org/bugs/show_bug.cgi?id=240143</font></a>
<br>
<br><font size=2 face="Courier New">I patched the the widget-ID as well,
this saves 13MB for all Text's and 30MB for the whole application.</font>
<br><font size=2 face="Courier New">String-IDs would still be possible
but are not taken by default.</font>
<br>
<br><font size=2 face="Courier New">Don't know whether it is worth it -
anyway you can decide which changes you apply.</font>
<br>
<br><font size=2 face="Courier New">Memory for Text-widgets after both
patches:</font>
<br>
<br><font size=2 face="Courier New">Class Name &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
Objects | Shallow Heap | Retained Heap | Retained Heap, % </font>
<br><font size=2 face="Courier New"> ------------------------------------------------------------ ---------------------------------------------------------- </font>
<br><font size=2 face="Courier New">org.eclipse.swt.widgets.Text &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;| 400.000 | &nbsp; 41.600.000 | &nbsp; &nbsp;96.000.000
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 22,72% </font>
<br><font size=2 face="Courier New">|- org.eclipse.swt.internal.widgets.WidgetAdapter
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | 400.000 | &nbsp; 12.800.000 | &nbsp;
&nbsp;19.200.000 | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;4,54% </font>
<br><font size=2 face="Courier New">| &nbsp;'- org.eclipse.swt.internal.widgets.IdGenerator$IntegerId|
400.000 | &nbsp; &nbsp;6.400.000 | &nbsp; &nbsp; 6.400.000 | &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;1,51% </font>
<br><font size=2 face="Courier New"> ------------------------------------------------------------ ---------------------------------------------------------- </font>
<br>
Re: Reducing RAP memory consumption (serverside / per session) [message #97600 is a reply to message #97370] Thu, 10 July 2008 11:09 Go to previous message
Eclipse User
Originally posted by: rherrmann.innoopract.com

Hi Stefan,

thanks for your patch. We well look into it as soon as time permits.

Cheers,
Rüdiger


stefan.hansel@tolina.de wrote:
>
> Patches can be found here ...
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=240143
>
> I patched the the widget-ID as well, this saves 13MB for all Text's and
> 30MB for the whole application.
> String-IDs would still be possible but are not taken by default.
>
> Don't know whether it is worth it - anyway you can decide which changes
> you apply.
>
> Memory for Text-widgets after both patches:
>
> Class Name | Objects |
> Shallow Heap | Retained Heap | Retained Heap, %
> ------------------------------------------------------------ ----------------------------------------------------------
>
> org.eclipse.swt.widgets.Text | 400.000 |
> 41.600.000 | 96.000.000 | 22,72%
> |- org.eclipse.swt.internal.widgets.WidgetAdapter | 400.000 |
> 12.800.000 | 19.200.000 | 4,54%
> | '- org.eclipse.swt.internal.widgets.IdGenerator$IntegerId| 400.000 |
> 6.400.000 | 6.400.000 | 1,51%
> ------------------------------------------------------------ ----------------------------------------------------------
>
Previous Topic:[RAP 1.1] Missing Constraint: org.eclipse.ui; version="0.0.0"
Next Topic:Theming for Form widgets
Goto Forum:
  


Current Time: Wed Aug 20 02:55:27 EDT 2014

Powered by FUDForum. Page generated in 0.01792 seconds