[vwnc] RB caching 10's of MB of data?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[vwnc] RB caching 10's of MB of data?

Randy Coulman
Since moving to 7.6, we've noticed the the RB seems to be caching a significant amount of data.  Over time, these caches can add 10's of MB to an image's size.  When I notice the image growth, I've found that the only way to get it to go away is to close any open RB windows and disconnect from all Store repositories and force a garbage collection from the launcher.  I typically have to do both things: close RBs _and_ disconnect from Store.  One or the other isn't enough (though maybe I just didn't wait long enough).

This problem is present in the 7.7 dev builds as well.

What is the RB caching, and does it really need to do that?  Do other people see this, or do we have some addon/extension that's contributing to the problem?

Thanks,
Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] RB caching 10's of MB of data?

Michael Lucas-Smith-2
It could be Glorp caching Store objects? Could you check any Glorp
sessions/caches you can find?

Michael

Randy Coulman wrote:

> Since moving to 7.6, we've noticed the the RB seems to be caching a
> significant amount of data.  Over time, these caches can add 10's of
> MB to an image's size.  When I notice the image growth, I've found
> that the only way to get it to go away is to close any open RB windows
> and disconnect from all Store repositories and force a garbage
> collection from the launcher.  I typically have to do both things:
> close RBs _and_ disconnect from Store.  One or the other isn't enough
> (though maybe I just didn't wait long enough).
>
> This problem is present in the 7.7 dev builds as well.
>
> What is the RB caching, and does it really need to do that?  Do other
> people see this, or do we have some addon/extension that's
> contributing to the problem?
>
> Thanks,
> Randy
> --
> Randy Coulman
> [hidden email] <mailto:[hidden email]>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>  

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] RB caching 10's of MB of data?

Randy Coulman

On Fri, Jul 17, 2009 at 1:44 PM, Michael Lucas-Smith <[hidden email]> wrote:
It could be Glorp caching Store objects? Could you check any Glorp sessions/caches you can find?


In my 7.6 dev images, I don't have Glorp loaded, and they still suffer from the problem.

Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] RB caching 10's of MB of data?

thomas.hawker
In reply to this post by Randy Coulman

Yes, I’ve seen it, but for the most part have ignored it.  My guess is that the cache seems to run about 15% of the amount of packages/classes in the system, but that’s just a quick guesstimate from a 30MB image and about 4-5MB recovery after closing the browser.

 

Cheers!

 

Tom Hawker

Senior Framework Developer

Home

+1 (408) 274-4128

The Environment:

We take it personally

Office

+1 (408) 576-6591

Mobile

+1 (408) 835-3643

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Randy Coulman
Sent: Friday, July 17, 2009 1:38 PM
To: VW NC
Subject: [vwnc] RB caching 10's of MB of data?

 

Since moving to 7.6, we've noticed the the RB seems to be caching a significant amount of data.  Over time, these caches can add 10's of MB to an image's size.  When I notice the image growth, I've found that the only way to get it to go away is to close any open RB windows and disconnect from all Store repositories and force a garbage collection from the launcher.  I typically have to do both things: close RBs _and_ disconnect from Store.  One or the other isn't enough (though maybe I just didn't wait long enough).

This problem is present in the 7.7 dev builds as well.

What is the RB caching, and does it really need to do that?  Do other people see this, or do we have some addon/extension that's contributing to the problem?

Thanks,
Randy
--
Randy Coulman
[hidden email]

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] RB caching 10's of MB of data?

Steffen Märcker
In reply to this post by Randy Coulman
I can confirm this. The only RB extension loaded in my images are
RBCodeHighlighting and RBTabbedToolset.

Cheers,
Steffen

Am 17.07.2009, 22:38 Uhr, schrieb Randy Coulman <[hidden email]>:

> Since moving to 7.6, we've noticed the the RB seems to be caching a
> significant amount of data.  Over time, these caches can add 10's of MB  
> to
> an image's size.  When I notice the image growth, I've found that the  
> only
> way to get it to go away is to close any open RB windows and disconnect  
> from
> all Store repositories and force a garbage collection from the  
> launcher.  I
> typically have to do both things: close RBs _and_ disconnect from Store.
> One or the other isn't enough (though maybe I just didn't wait long  
> enough).
>
> This problem is present in the 7.7 dev builds as well.
>
> What is the RB caching, and does it really need to do that?  Do other  
> people
> see this, or do we have some addon/extension that's contributing to the
> problem?
>
> Thanks,
> Randy
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] RB caching 10's of MB of data?

Randy Coulman
In reply to this post by thomas.hawker

On Fri, Jul 17, 2009 at 1:50 PM, <[hidden email]> wrote:

Yes, I’ve seen it, but for the most part have ignored it.  My guess is that the cache seems to run about 15% of the amount of packages/classes in the system, but that’s just a quick guesstimate from a 30MB image and about 4-5MB recovery after closing the browser.

 

I've seen much worse than this (20-40MB in a 45MB image).

I just had an image with some growth here, and so ran a class report on instance size before and after, and it looks like a lot of RB Parser objects (RB*Node and RB*Token) instances.  Is something caching parse trees maybe?

Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] RB caching 10's of MB of data?

Holger Guhl
This reminds me to a VisualWorks 7.6 support case with we had with ExtraEmphasis involved.
Users had observed images growing and gave hints on RB as the culprit.

Solution was to use version "43" of package ExtraEmphasis which introduced a cache for the big red STOP image used to mark a breakpoint. Its blessing comment says "cache the stop image so we don't keep recreating it over and over and over and over again". The previously delivered version let the image fetch the stop glyph on each time a breakpoint had to be displayed or redisplayed. An ExtendedFontDecription had to be created each time and by conditions I did not fully understand, the RB kept hold of objects involved and let the image grow.

But this is only a desperate guess, and I would not expect to see that in VW 7.7 ...
Holger Guhl
-- 
Senior Consultant * Certified Scrum Master * [hidden email]
Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20
Georg Heeg eK Dortmund
Handelsregister: Amtsgericht Dortmund  A 12812


Randy Coulman schrieb:

On Fri, Jul 17, 2009 at 1:50 PM, <[hidden email]> wrote:

Yes, I’ve seen it, but for the most part have ignored it.  My guess is that the cache seems to run about 15% of the amount of packages/classes in the system, but that’s just a quick guesstimate from a 30MB image and about 4-5MB recovery after closing the browser.

 

I've seen much worse than this (20-40MB in a 45MB image).

I just had an image with some growth here, and so ran a class report on instance size before and after, and it looks like a lot of RB Parser objects (RB*Node and RB*Token) instances.  Is something caching parse trees maybe?

Randy
--
Randy Coulman
[hidden email]

_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] RB caching 10's of MB of data?

Randy Coulman


On Fri, Jul 17, 2009 at 2:50 PM, Holger Guhl <[hidden email]> wrote:
This reminds me to a VisualWorks 7.6 support case with we had with ExtraEmphasis involved.
Users had observed images growing and gave hints on RB as the culprit.

Solution was to use version "43" of package ExtraEmphasis which introduced a cache for the big red STOP image used to mark a breakpoint. Its blessing comment says "cache the stop image so we don't keep recreating it over and over and over and over again". The previously delivered version let the image fetch the stop glyph on each time a breakpoint had to be displayed or redisplayed. An ExtendedFontDecription had to be created each time and by conditions I did not fully understand, the RB kept hold of objects involved and let the image grow.

But this is only a desperate guess, and I would not expect to see that in VW 7.7 ...

Nice guess, but we've been using 43 and newer of ExtraEmphases for some time now, and we still have the problem.

Thanks,
Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] RB caching 10's of MB of data?

thomas.hawker
In reply to this post by Randy Coulman

Steffen commented that he only had RBCodeHighlighting loaded.  That uses SmaCC and only uses SmaCC tokens briefly while it parses to assign the formatting.  The text can get quite complex with all of the various formatting objects involved, but that wouldn’t be the parse trees.

 

My digging around in the browser makes me wonder just how much is actually getting saved.  The RBParser stuff is called all over the place, especially if you do refactorings.  I had to make that pluggable (because GemStone code uses different syntax).  I thought some of the typing information was cached – but I’m not sure.

 

Cheers!

 

Tom Hawker

Senior Framework Developer

Home

+1 (408) 274-4128

The Environment:

We take it personally

Office

+1 (408) 576-6591

Mobile

+1 (408) 835-3643

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Randy Coulman
Sent: Friday, July 17, 2009 2:04 PM
To: [hidden email]
Subject: Re: [vwnc] RB caching 10's of MB of data?

 

 

On Fri, Jul 17, 2009 at 1:50 PM, <[hidden email]> wrote:

Yes, I’ve seen it, but for the most part have ignored it.  My guess is that the cache seems to run about 15% of the amount of packages/classes in the system, but that’s just a quick guesstimate from a 30MB image and about 4-5MB recovery after closing the browser.

 

I've seen much worse than this (20-40MB in a 45MB image).

I just had an image with some growth here, and so ran a class report on instance size before and after, and it looks like a lot of RB Parser objects (RB*Node and RB*Token) instances.  Is something caching parse trees maybe?

Randy
--
Randy Coulman
[hidden email]

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc