>> Again, I was under the impression that you have some (semi-) automatic
>> test application that you could just re-run after an SVN update
(comparing
>> files sounds more like analysis). Maybe we could run this application
on
>> our side as well?!
I posted this 'application' add the end of th
Am 20.08.2008 um 22:03 schrieb [EMAIL PROTECTED]:
>>> Until this mail the colloboration was quite friendly and your
>>> feedback
>>> was really helpful.
>
> So then sorry for overreacting a bit. After a long working day it
> was just
> too depressing to see the numbers drop so bad.
> To start
Stefan,
> So then sorry for overreacting a bit. After a long working day it was just
> too depressing to see the numbers drop so bad.
You shouldn't be more depressed than we are ;).
> SVN access is s slow (not your fault of course). Doing a
> compare on a single file takes more than
>> Until this mail the colloboration was quite friendly and your feedback
>> was really helpful.
So then sorry for overreacting a bit. After a long working day it was just
too depressing to see the numbers drop so bad.
To start collaboration again: your last checkin (15910) on ui.core.Widget
co
[EMAIL PROTECTED] wrote:
>>> Maybe you can re-run your tests again :) Most core disposer issues,
>>> especially LayoutItem, Widget, etc. were fixed. Would be interesting if
>>>
>
>
>>> this results in any improvements for your test.
>>>
>
> It got worse (using trunk rev 15905).
>
[EMAIL PROTECTED] schrieb:
>>> Maybe you can re-run your tests again :) Most core disposer issues,
>>> especially LayoutItem, Widget, etc. were fixed. Would be interesting if
>
>>> this results in any improvements for your test.
>
> It got worse (using trunk rev 15905).
> After 3000 qx.ui.core.
>> Maybe you can re-run your tests again :) Most core disposer issues,
>> especially LayoutItem, Widget, etc. were fixed. Would be interesting if
>> this results in any improvements for your test.
It got worse (using trunk rev 15905).
After 3000 qx.ui.core.Widgets I stopped. Leaked already >50M
[EMAIL PROTECTED] schrieb:
>>> Yes, but the question I guess was: Is there a leak in 0.7?!
>
> O yes - at least as big as it was in 0.8 yesterday ... I only focused
> now on 0.8 because it was easier to debug/understand due to the new
> DOM-handling stuff.
>
> I just quote from my first pos
>> Yes, but the question I guess was: Is there a leak in 0.7?!
O yes - at least as big as it was in 0.8 yesterday ... I only focused
now on 0.8 because it was easier to debug/understand due to the new
DOM-handling stuff.
I just quote from my first posting:
>> After 3000 Labels the IE7 memor
thron7 schrieb:
> Sebastian Werner wrote:
>> Benjamin Muskalla schrieb:
>>
>>> Sebastian Werner wrote:
>>>
Benjamin Muskalla schrieb:
> Hi Sebastian,
>
> qx.ui.menu.Button:80 the changeLocale listener gets added but never
> removed in the destructor.
>
Sebastian Werner wrote:
> Benjamin Muskalla schrieb:
>
>> Sebastian Werner wrote:
>>
>>> Benjamin Muskalla schrieb:
>>>
Hi Sebastian,
qx.ui.menu.Button:80 the changeLocale listener gets added but never
removed in the destructor.
>>> Mhh, I do not ha
Benjamin Muskalla schrieb:
> Sebastian Werner wrote:
>> Benjamin Muskalla schrieb:
>>> Hi Sebastian,
>>>
>>> qx.ui.menu.Button:80 the changeLocale listener gets added but never
>>> removed in the destructor.
>> Mhh, I do not have this code. Infact the whole class do not have a
>> changeLocale lis
Sebastian Werner wrote:
> Benjamin Muskalla schrieb:
>> Hi Sebastian,
>>
>> qx.ui.menu.Button:80 the changeLocale listener gets added but never
>> removed in the destructor.
>
> Mhh, I do not have this code. Infact the whole class do not have a
> changeLocale listener.
Sorry, forgot to mention
Benjamin Muskalla schrieb:
> Hi Sebastian,
>
> we saw there are several changes regarding widget disposal in current
> trunk. Would it be possible to backport them to the 0.7 branch to see if
> they lead to an improvement of the current situation?
This is already done in 0.7. We have had just n
Hi Sebastian,
we saw there are several changes regarding widget disposal in current
trunk. Would it be possible to backport them to the 0.7 branch to see if
they lead to an improvement of the current situation?
And by the way: The kind of bug which was now fixed for Label as
discussed in this
cool stuff, great :)
> Have some great and some 'bad' news:
>
> great: the big memory problems of labels are gone
> 'bad': My claim that ui.core.Widgets have no memory-problem from the last
> post was wrong.
> This was from a test, where widgets were created and destroyed instantly,
> without ad
Have some great and some 'bad' news:
great: the big memory problems of labels are gone
'bad': My claim that ui.core.Widgets have no memory-problem from the last
post was wrong.
This was from a test, where widgets were created and destroyed instantly,
without adding them to the root.
My current
>
>> - playing around with qx.html.Element instead of Labels: don't suffer
>> memory-leaks as well when used to manipulate DOM.
>
> Can you test qx.html.Label as well? This would help to differ between
> pure Elements and the elements used in the widget Label class.
There was a major leak in t
[EMAIL PROTECTED] schrieb:
>>> Anyway, we'll have to take a very close look at the memory problems you
> have reported.
>
> Maybe to safe some time for further investigations:
>
> - For current tests I just use destroy- and no dispose-calls.
Fine.
> - Using one class above Labels (i.e. Widgets
> The (very !) minimal amount still rising (only on a now very
> large widget sets) can be tracked down to arrays wich hold
> hash-values of objects.
> Adding and removing from javascript-arrays with always changing
> ids leaks on IE and can be reproduced without qooxdoo as well.
Very inter
>> Anyway, we'll have to take a very close look at the memory problems you
have reported.
Maybe to safe some time for further investigations:
- For current tests I just use destroy- and no dispose-calls.
- Using one class above Labels (i.e. Widgets) the memory consumption is
not as drastic (tes
Am 15.08.2008 um 17:40 schrieb [EMAIL PROTECTED]:
>>> No, 0.7.3 has no such option. There is no equivalent.
>
> Since I'm still hoping that there is an easy solution for RAP and
> qooxdoo
> 0.7.3:
>
> How do I correctly get rid of a widget in 0.7.3 if not calling
> disconnect() (or setParent(nu
>> No, 0.7.3 has no such option. There is no equivalent.
Since I'm still hoping that there is an easy solution for RAP and qooxdoo
0.7.3:
How do I correctly get rid of a widget in 0.7.3 if not calling
disconnect() (or setParent(null) ) and then dispose() ?
[EMAIL PROTECTED] schrieb:
>>> I would not be surprised if the base line memory consumption of the
>>>
> qooxdoo app
>
>>> is above GWT and dojo as qooxdoo widgets are probably more complex than
>>>
> those.
>
> No problem with that.
>
>
>>> BTW to my knowledge the RAP guys
[EMAIL PROTECTED] schrieb:
>>> I would not be surprised if the base line memory consumption of the
> qooxdoo app
>>> is above GWT and dojo as qooxdoo widgets are probably more complex than
> those.
>
> No problem with that.
>
>>> BTW to my knowledge the RAP guys at Innoopract are working to
>> I would not be surprised if the base line memory consumption of the
qooxdoo app
>> is above GWT and dojo as qooxdoo widgets are probably more complex than
those.
No problem with that.
>> BTW to my knowledge the RAP guys at Innoopract are working to add
widget
>> pooling in the next 0.8
One thing which is wrong in your qooxdoo code is that you call dispose
and destroy. For widget destroy is the better alternative when you
really want to remove the element (which means from the DOM as well).
When you call dispose() afterwards this effect is torpedated.
Sebastian
Fabian Jakobs
Hi Stefan,
thank you for sharing these results. We will have a very close look at
the memory consumption of your script. I would not be surprised if the
base line memory consumption of the qooxdoo app is above GWT and dojo as
qooxdoo widgets are probably more complex than those. But the increa
If was asked to provide GWT-code as well, since it's not much I'll post
the source here.
To create a webapp, you'll have to download GWT 1.5, and do the following
as described in the getting started guide (
http://code.google.com/webtoolkit/gettingstarted.html)
1) call 'projectCreator de.tolina
Integrated pooling directly to qooxdoo for faster execution can be
great, I will vote for it :-)
But, for me is interesting footprint of GWT
- Petr
2008/8/13 Jim Hunter <[EMAIL PROTECTED]>:
> At this point, I have not created a 'global' way of doing it. I got very
> close yesterday, but 'time to
At this point, I have not created a 'global' way of doing it. I got very
close yesterday, but 'time to go home' came and I had done 4 late night
sessions in a row so I put down the keyboard and went home. If I get it
fixed in a global way today, I will send the author a patch.
Thanks for your sugge
On Wed, Aug 13, 2008 at 11:33 AM, Jim Hunter <[EMAIL PROTECTED]> wrote:
> The one thing to watch out for that is not covered in the pooling class are
> events listeneres. You need to remove the event listeners when you pool
> objects otherwise they start to accumulate and you get multiple actions
You may not want to do pooling, but it has two really nice side effects:
1) It gets rid of your memory creep
2) It makes your program faster. It is much faster to re-use an object then
it is to create a new one.
I spent about a week changing my large application over to using pooling and
it is so
Hi Stefan,
thanks for your input.
> I planned to provide my qooxdoo-(0.8)-script, as well as GWT and Dojo
> examples of the same scenario as a comparison.
> Unfortunataly the newsgroup doesn't accept this - any idea how i can
> provide this ?
Regarding the (I suppose larger) files, you could ju
At least the sourcecode for the qooxdoo app ... if wanted I'll provide dojo +
gwt source-code as well.
qx.Class.define("Application",
{
extend : qx.application.Standalone,
members :
{
map : new Array(),
offset : 0,
refresh: function(e) {
for ( var int = 0; int <
Hi there,
we are working on a bigger RAP application and as others do face the problem,
that memory consumption of a single-page application increases very fast in IE.
To track bugs down I started to write a really simple qooxdoo-test-app trying
to reproduce the problem and this wasn't to hard
36 matches
Mail list logo
