cocoaforge

Hello, all.

I was recently using my computer, and everything slowly started to slow down as if I was slowly running out of RAM. I opened up Activity Monitor to take a look, and found out that GrowlHelperApp was using 385mb of RAM, all by itself. I'm pretty sure this is a memory leak; does this have to do with using the newest version of WebKit(I don't remember it happening before I upgraded), or is this something different?

Thanks,
Girasquid

Growl 1.1 will have a lot of memory improvements. However, if you are utilizing a display which uses webkit, that could also explain it.

Which display are you using?

I'm using the Candybars display style.

That's a webkit display

Same here, it's using 392MB at the moment. I'm using the Crystal display style, should I change it to another one that doesn't use WebKit, at least until this "bug" is fixed?

Crystal is also webkit, so changing it from that should help.

You're also welcome to try the beta.

Sorry to bump thois old thead but I have to say I'm quite disappointed with Growl 1.1.1. I thought it was related to the previous BETA but even now GrowlHelperApp and GrowlTunes both use betwen 100 and 300MB. I have to stop Growl and restart it quite often because it uses too much memory. I have a widget displaying the 5 biggest memory consuming applications and with 0.76 Growl wasn't ever in the list. Now it's always in the top 3.
I have Tunes, Safari and Mail open almost everytime I use my computer so that may be causing Growl to "work" too hard but it's still an issue for me.
Otherwise I thank you very much for 1.1.1 because the new features are great and Growl is an amazing piece of app

PS: You told me to try to use a non-webkit display, I tried a lot but don't really know which ones are webkit and which ones aren't. Could you please give a few names?

Non-Webkit: Smoke, MusicVideo, Bubbles, Nano, iCal

arnoz wrote:I thought it was related to the previous BETA but even now GrowlHelperApp and GrowlTunes both use betwen 100 and 300MB.

When testing a beta, it's a good idea to tell us when things like this happen, and then follow up with us.

Anyhow, try one that bgannin listed.

I'm going to try Bubbles for a few days.
I thought that this topic was already enough for you. But I'll report more often on BETA next time, sorry!

arnoz wrote:I'm going to try Bubbles for a few days.
I thought that this topic was already enough for you. But I'll report more often on BETA next time, sorry!

No worries, we just get a lot of folks who think they can't report things until after a beta period, I wanted to make sure that you understood that this is indeed not the case.

So, if this is a WebKit problem would a no-cache (like this) tag be respected? If so, would there be any significant problems for the GrowlHelperApp such as performance issues?

Nib wrote:So, if this is a WebKit problem would a no-cache (like this) tag be respected?

Code: Select all

<meta http-equiv="Pragma" content="no-cache">

If so, would there be any significant problems for the GrowlHelperApp such as performance issues?

Give it a try, Go into the app bundle and add that. If it helps with performance I that'd be awesome.

The_Tick wrote:Give it a try, Go into the app bundle and add that. If it helps with performance I that'd be awesome.

First test with approximately 700 notifications from a variety of applications during a 7 hour period shows negative results, GrowlHelperApp still gets an inflated memory footprint. Though I will have to run a few more tests to eliminate sampling errors to be completely sure.

Nib wrote:

The_Tick wrote:Give it a try, Go into the app bundle and add that. If it helps with performance I that'd be awesome.

First test with approximately 700 notifications from a variety of applications during a 7 hour period shows negative results, GrowlHelperApp still gets an inflated memory footprint. Though I will have to run a few more tests to eliminate sampling errors to be completely sure.

After studying GrowlHelperApp vhile sending it 2000+ notifications and determining that it does indeed still use over 1GByte of virtual memory and does not honor the header meta tag. I also found out that Safari shows an identical memory footprint change when I constantly load the plugin there.

This gave me an idea. Looking into the Xcode documentation I found this:

Enabling and Disabling the Back-Forward List

By default, every WebView object maintains its own back-forward list object. There is some overhead in maintaining this list. If you don't want to use this feature, send a setMaintainsBackForwardList: message to your WebView object as in:

Code: Select all

[webView setMaintainsBackForwardList:NO];

Otherwise, history items, which encapsulate visited page information, are automatically added and removed from the back-forward list as webpages are loaded and displayed in a WebView. If you maintain a back-forward list in your WebView object, then you should add some buttons to your user interface so that users can use this feature.

And this:

Setting the Page Cache

You can use back-forward lists to maintain a page cache too. Because pages in the cache are rendered quickly, using this feature improves the performance of the back-forward action methods. You can turn this feature on or off by setting the cache size using the WebBackForwardList setPageCacheSize: method. If you set the page cache size to 0, the page cache is disabled; otherwise, the size of the cache is limited to the number of pages you specify. The default page cache size may vary depending on your computer’s configuration. Use the pageCacheSize method to get the current setting.

Code: Select all

- (void)setPageCacheSize:(unsigned)size

Perhaps this is what we are looking for? Since Safari needs the cache but GrowlHelperApp does not. At least not to the same extent.

As I am not well-trained in either Growl Development or Cocoa in general I failed to add any code and compile the application I have to leave it to someone else to continue.

Woah, awesome find!

Nib wrote: As I am not well-trained in either Growl Development or Cocoa in general I failed to add any code and compile the application I have to leave it to someone else to continue.

Well training, schmell training. Pshaw.

Where are you stuck?

The_Tick wrote:Woah, awesome find!

Nib wrote: As I am not well-trained in either Growl Development or Cocoa in general I failed to add any code and compile the application I have to leave it to someone else to continue.

Well training, schmell training. Pshaw.

Where are you stuck?

Sorry about not returning to you earlier, too much work at the moment.

I guess what I am looking for is either the very first instance where the Web Kit style is loaded/fetched or something similar.

I am also having problem with the SVN, I get an error when trying to update from the trunk:

svn: Can't convert string from 'UTF-8' to native encoding:
svn: Extras/GrowlMail/Instalac?\204?\167a?\204?\131o do GrowlMail.rtf

I have also tried to use the WOCachingEnabled NO by writing this to the terminal:
But without any luck.

http://growl.info/documentation/develop ... nstall.php has the command you need to issue that'll get you around that encoding error.

Nib wrote:I have also tried to use the WOCachingEnabled NO by writing this to the terminal:

Code: Select all

defaults write com.Growl.GrowlHelperApp.plist WOCachingEnabled NO

But without any luck.

This wouldn't have any effect, GrowlHelperApp isn't a WebObjects application, nor does it use WebObjects.