Home » Eclipse Projects » Remote Application Platform (RAP) » memory consumption under IE
| memory consumption under IE [message #106602] |
Fri, 26 September 2008 13:12  |
 Alex
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
Hi all,
I've been working on a small prototype to evaluate the RAP technology and
was stuck with the memory consumption under IE. My application places quite
a burden on the client as it allocates lots of controls within nested
intermediate panels, but Firefox is able to handle it without problems.
However the application is unusable under IE, which consumes 7 times as much
memory compared to Firefox!
I've been told that IE is a big memory hog compared to other browsers, but
could it be blamed alone for this factor 7 or could also be some issue
related with RAP or qooxdoo? Does anyone know of a javascript benchmark that
shows similar numbers?
Attached you find a screenshot of my application and a short description
below.
Thanks in advance for any help,
Alex
It is a logistics application that consumes a lot of memory because it
allocates a very large number of widgets. The critical structure is some
sort of table where each element (representing a shipment) is a very complex
widget with several labels and subpanels. My table has 100 of such widgets.
Each one of them may be further expanded by the user to display 10 more
subwidgets inside it, and each one of these subwidgets in turn (representing
the orders corresponding to that shipment) is also a very complex widget
with several labels and subpanels! In order to optimize memory consumption,
I create these subwidgets on demand as the user expands one of the parent
widgets.
The application runs well under firefox: it opens up with 38 MB and rises
to 110 MB when I load my table with 100 widgets. From this point, each
subwidget expansion takes up an average of 7 MB.
I can not run such application under IE: it opens up with 59 MB, climbs to
524 MB right away after displaying the table with 100 widgets and each
further subwidget expansion eats up 50 MB!
I don't think this could be caused by a memory leak in qooxdoo, as in my
tests I am only creating new widgets and never disposing them.
|
|
|
| Re: memory consumption under IE [message #107259 is a reply to message #106602] |
Tue, 30 September 2008 16:18  |
Stefan Hansel
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
Alex,
as already said in the qooxdoo newsgroups I can't tell you if it is
'normal' in your case, that IE takes 7times more memory.
All I know is, that IE takes much more memory for JS-objects than firefox.
That's why the memory-problems when adding/removing widgets are so much
higher than in firefox (even though in FF they exist as well).
Anyway - also 100MB in FF sound very high - and considering the amount of
memory used on the server-side for this, I'm afraid you won't be able to
serve a very big count of users with your current UI-design.
I'm pretty convinced, that you will get out-of-memory very soon on the
serverside, when the user-count increases.
Some ideas I had to improve your situation, if you are allowed to change
the UI design (otherwise talk to your architects or UI-designers, or you
won't get happy with RAP I'm afraid).
- you should load the contents of the table 'lazy' (not only when
expanding an item). You should also release rows, which are invisible to
the user.
SWT-tables have a feature called 'SWT.VIRTUAL' which seems to be exactly
what you would need for that. (Though I'm not sure, whether you use a
'real' SWT-table).
- As an alternative consider paging of the table contents. There are good
reasons, why google doesn't show all search results at once ;-) ...
Also all desktop-applications I know don't show >100 items in the same
table, as the propability that the users finds the desired row is very
low.
(I have to correct myself - my favourite *cough*
email/newsgroups-program lotus notes shows more than 100 items at once ...
nevertheless I'm not able to find older mails in that view so its useless
anyway ;-) )
- don't overwhelm the user with every piece of information on one screen.
For instance instead of expanding table-items you could present a
popup-dialog with the same data, which quite better catches the humans eye
and seperates the data.
As a side effect: users couldn't expand more than one row which should
safe overall memory consumption.
- taking the last step a bit further: instead of opening a new dialog, you
could open a new tabs/views on the top bar.
Since at any time only one tab can be visible, the content of tabs could
be disposed when unselected, thus saving memory on the client as on the
server-side as well.
This of course needs some custom logic, which you need to write for
yourself.
(most 'difficult' part is, to remember current selections etc. so that
when recreating the content it looks to the user as if he never left).
We already did this with good results - the user thinks a lot of tabs
are open - and a lot of information is at his fingertips. As recreating
the content of a tab is quite fast
in our scenario he virtually doesn't realize that the content is
recreated on-the-fly.
All the points written here won't help you with the current RAP-version on
IE as there is still this memory-leak which prevents any strategies that
involve adding/disposing widgets a lot.
As we heavily use the strategies above to make our applications
memory-friendly on client and server-side (and already succeded at the
server-side at least) we will very strongly see, that the memory issues
are resolved for RAP v1.1.2 in february (which looks very promising so
far).
Regards,
Stefan
|
|
|
| Re: memory consumption under IE [message #107323 is a reply to message #107259] |
Tue, 30 September 2008 21:29 |
Alex
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
Hi Stefan,
Once again, thank you very much for all your help! I tried to post this
message to the qooxdoo thread we were discussing, but it got stuck due to
the large size of the attachments with the screenshots. Anyway, since I can
not easily create a standalone qooxdoo application to expose the problem I
though it would be more convenient to ask for help in RAP's forum.
Please see my notes below:
> memory used on the server-side for this, I'm afraid you won't be able to
> serve a very big count of users with your current UI-design.
> I'm pretty convinced, that you will get out-of-memory very soon on the
> serverside, when the user-count increases.
That was also my main worry when I started analyzing the memory consumption
of the application. However I found out that it consumes "only" 20 MB on the
server side with a single user. So I think it would be optimistic to say
that it could stand at least 50 simultaneous users on a 2 GB machine, and
our application will typically serve less than 20. Of course I still need to
prove that with JMeter tests, but I was surprised with the memory
consumption on the client side in IE which I didn't expect.
> - you should load the contents of the table 'lazy' (not only when
> expanding an item). You should also release rows, which are invisible to
> the user.
That would be necessary for IE only, since 100 MB in Firefox is acceptable.
I would prefer to do it this way to make the application more responsive as
the user scrolls the table.
> SWT-tables have a feature called 'SWT.VIRTUAL' which seems to be exactly
> what you would need for that. (Though I'm not sure, whether you use a
> 'real' SWT-table).
It's not really an SWT table, it's just a composite panel where I keep
stacking my custom controls.
> - As an alternative consider paging of the table contents. There are good
> reasons, why google doesn't show all search results at once ;-) ...
> Also all desktop-applications I know don't show >100 items in the same
> table, as the propability that the users finds the desired row is very
> low.
Yes, I agree! I also made this suggestion to change the design, but the
staff that works with user support insisted that the system should stand at
least 100 elements on a single screen. It amazes me how can someone deal
with such a large amount of information, but I was told this system is
typically used by someone who's used to do this task every day.
> - taking the last step a bit further: instead of opening a new dialog, you
> could open a new tabs/views on the top bar.
> Since at any time only one tab can be visible, the content of tabs could
> be disposed when unselected, thus saving memory on the client as on the
> server-side as well.
Yes, that would be great. Basically I have two problems in IE:
- loading a table of 100 elements takes 500 MB,
- each widget expansion takes up an additional of 50 MB.
I also thought about creating a lower panel in order to display a single
element at a time as you suggest. That would solve the second issue once the
qooxdoo guys solve the memory leak issues, but I still need to show the 100
elements in the table as I told you. I could follow your suggestion of
optimizing it further and loading/disposing widgets when the table is
scrolled (still need to investigate the impact of this on the user
experience), but I would like to know what makes my application so memory
consuming under IE compared to Firefox. This is what makes me worried with
the memory consumption of RAP applications in IE.
> server-side at least) we will very strongly see, that the memory issues
> are resolved for RAP v1.1.2 in february (which looks very promising so
> far).
Yes, that's very promising. It would be even greater if the RAP team could
make an intermediate build incorporating some qooxdoo patch. If we find out
what's wrong with the memory consumption in IE we could still adopt RAP in a
new project for the end of this year.
Best regards,
Alex
|
|
| |
| Re: memory consumption under IE [message #107505 is a reply to message #107350] |
Wed, 01 October 2008 13:08 |
Alex
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
Hi Stefan,
> So this is at least not factor 7, which is good on the one hand :D ... on
> the other factor 4 is not too good either ...
That makes me start to agree with you that a factor of 7 could indeed be all
IE's fault and have nothing to do with RAP or qooxdoo. That's too bad, since
the RAP or qooxdoo team wouldn't be able to make any miracles to improve the
situation. Of course we would like to tell our clients to forget about IE,
but 90% of them will just forget about us! :-)
> (By the way IE7 is very slow to create those pages and always asks if I
> want to abort the script - )
Yes, I get this message all the time. It's very annoying. I would try to get
rid of it by starting a background job to show a progress bar in the
workbench for every lengthy operation, but did not manage to make the
experiment to see if it works.
> Note that I only tested with simple labels - results could be totally
> different when using checkboxes or combos.
Yes, it is different. My application has a bunch of labels grouped within
nested composites and a few combos. It starts with about 500 MB compared to
your value of 135 MB when creating 1000 labels.
> Given that, I doubt that what you are seeing is a RAP or qooxdoo problem.
It is hard to believe that IE could be that bad, but your experiment with
plain labels is starting to convince me. A label is the simplest widget
there is and perhaps should be mapped to a single div in the DOM; I don't
think that would be a qooxdoo's fault to make it so memory consuming. By the
way, did you try to carry on a similar experiment with other sophisticated
javascript libraries, such as GWT?
Thanks,
Alex
|
|
| |
| Re: memory consumption under IE [message #107606 is a reply to message #107543] |
Thu, 02 October 2008 08:09 |
Stefan Hansel
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
>> He did :-) Take a look at
>>
http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg03965.html
>> and
http://thread.gmane.org/gmane.comp.lang.javascript.qooxdoo.d evel/15870
These tests never measured how much memory would be taken if all of these
widgets were shown at once.
They merely created/destroyed widgets in batches of 500 to test for memory
leaks.
I reanimated my GWT-workspace and rewrote the little snippet to create x
labels at once ... and as you will see GWT is far better with memory usage
than qooxdoo.
I tested with qooxdoo 0.8.x as well, just to see if anything will improve
if RAP switches. Here are the numbers:
5000 labels at once, qooxdoo 0.7.x, FF3/IE7 : 151MB / 441MB
5000 labels at once, qooxdoo 0.8.x. FF3/IE7 : 120MB / 220MB
5000 labels at once, GWT FF3/IE7 : 60MB / 41MB
(yes - GWT needs less memory on IE7)
I'm not sure, if this is a fair comparison, because qooxdoo is an
object-oriented-JS-framework - thus definitely needs more overhead to
handle all objects/classes, so they can be easily accessed by
JS-developers.
GWT is object-oriented as well - but only through its java-code - the
resulting JS is purely functional and can't be coded against.
Also I'm not sure, whether the GWT compiler could optimize my little
snippet more than it would have been able in a real application.
Anyway - as an application-developer you might not care about this.
You have to consider writing the serverside completely from scratch with
GWT - and to test GWT with bigger apps and other widgets as well, before
you draw conclusions.
And after seeing those numbers I hope again, that the RAP team officially
puts 0.8 migration on their RAP 1.2 plan :D
Regards
Stefan
|
|
|
| memory consumption under IE [message #107864 is a reply to message #106602] |
Thu, 02 October 2008 13:57 |
Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi Alex,
we are currently doing investigations that exactly targeting the
question if IE is to be blamed alone for this factor, or if there are
other issues related to RAP or Qooxdoo causing these problems. So we
agreed on several test scenarios which hopefully should provide us with
enough data to bring some light into this.
But your real world scenario with your kind of table widget is very
interesting to us. Is it possible to extract that widget out of your
application -so let's say without any kind of databinding - just
creating it with the same content over and over again? So we can also
have a look at this and investigate what's going on in terms of memory
usage in IE?
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Alex Ignácio da Silva [mailto:alex.silva@neolog.com.br]
Bereitgestellt: Freitag, 26. September 2008 15:12
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: memory consumption under IE
Betreff: memory consumption under IE
Hi all,
I've been working on a small prototype to evaluate the RAP technology
and was stuck with the memory consumption under IE. My application
places quite a burden on the client as it allocates lots of controls
within nested intermediate panels, but Firefox is able to handle it
without problems.
However the application is unusable under IE, which consumes 7 times as
much memory compared to Firefox!
I've been told that IE is a big memory hog compared to other browsers,
but could it be blamed alone for this factor 7 or could also be some
issue related with RAP or qooxdoo? Does anyone know of a javascript
benchmark that shows similar numbers?
Attached you find a screenshot of my application and a short description
below.
Thanks in advance for any help,
Alex
It is a logistics application that consumes a lot of memory because it
allocates a very large number of widgets. The critical structure is some
sort of table where each element (representing a shipment) is a very
complex widget with several labels and subpanels. My table has 100 of
such widgets.
Each one of them may be further expanded by the user to display 10 more
subwidgets inside it, and each one of these subwidgets in turn
(representing the orders corresponding to that shipment) is also a very
complex widget with several labels and subpanels! In order to optimize
memory consumption, I create these subwidgets on demand as the user
expands one of the parent widgets.
The application runs well under firefox: it opens up with 38 MB and
rises to 110 MB when I load my table with 100 widgets. From this point,
each subwidget expansion takes up an average of 7 MB.
I can not run such application under IE: it opens up with 59 MB, climbs
to
524 MB right away after displaying the table with 100 widgets and each
further subwidget expansion eats up 50 MB!
I don't think this could be caused by a memory leak in qooxdoo, as in my
tests I am only creating new widgets and never disposing them.
|
|
|
| memory consumption under IE [message #107895 is a reply to message #107505] |
Thu, 02 October 2008 13:57 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
as I've allready mentioned in another thread we are currently conducting
tests regarding the memory consumption (particular in IE). We will run
equal tests with qooxdoo 0.7-, 0.8- standalone, GWT and RAP and
hopefully get sufficient information to answer the question who is to
blame...
Last week we did just a simple smoketest with 100 Labels on a RAP shell
compared to 100 Labels in a GWT app on IE (Beta 8 for that matter). We
experienced that the labels in the GWT app needed only a fraction of the
memory that the labels in the RAP app with the 0.7.3 version of qooxdoo
consumed. But note this was just a quick experiment, so we'll wonder
what our tests come up with.
We'll expect to have results next week and we'll keep you posted...
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Alex Ignácio da Silva [mailto:alex.silva@neolog.com.br]
Bereitgestellt: Mittwoch, 1. Oktober 2008 15:08
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: memory consumption under IE
Betreff: Re: memory consumption under IE
Hi Stefan,
> So this is at least not factor 7, which is good on the one hand :D ...
on
> the other factor 4 is not too good either ...
That makes me start to agree with you that a factor of 7 could indeed be
all
IE's fault and have nothing to do with RAP or qooxdoo. That's too bad,
since
the RAP or qooxdoo team wouldn't be able to make any miracles to improve
the
situation. Of course we would like to tell our clients to forget about
IE,
but 90% of them will just forget about us! :-)
> (By the way IE7 is very slow to create those pages and always asks if
I
> want to abort the script - )
Yes, I get this message all the time. It's very annoying. I would try to
get
rid of it by starting a background job to show a progress bar in the
workbench for every lengthy operation, but did not manage to make the
experiment to see if it works.
> Note that I only tested with simple labels - results could be totally
> different when using checkboxes or combos.
Yes, it is different. My application has a bunch of labels grouped
within
nested composites and a few combos. It starts with about 500 MB compared
to
your value of 135 MB when creating 1000 labels.
> Given that, I doubt that what you are seeing is a RAP or qooxdoo
problem.
It is hard to believe that IE could be that bad, but your experiment
with
plain labels is starting to convince me. A label is the simplest widget
there is and perhaps should be mapped to a single div in the DOM; I
don't
think that would be a qooxdoo's fault to make it so memory consuming. By
the
way, did you try to carry on a similar experiment with other
sophisticated
javascript libraries, such as GWT?
Thanks,
Alex
|
|
|
Goto Forum:
Current Time: Wed Apr 24 23:01:07 GMT 2024
Powered by FUDForum. Page generated in 0.03297 seconds |
] 
Search
Help
Register
Login
Home
