Memory Usage
Andrew Krivosheyenko
custom application tracking event log and sending some messages to
growl, during the day it can be hundreds of messages sent (50-500
bytes long each)... and task manager shows 400-500 MB of private bytes
for the growl process at the end of the day. Right now, after growl
restart, it's 202 MB of private working set, seems to be quite a lot
for such an utility sitting in the tray and showing windows.
The only TranslucentDark as a display is used, two apps are registered
(VS 2008 plugin and my app).
There are a number of other displays installed (downloaded from Growl
site) but not used.
p.s. while writing this message, I went to history section and cleared
all saved events. private working set bytes dropped from 220 to 50 MB!
can I somehow disable history tracking (via grow.exe config) or
something?
Brian, please consider adding an option to UI to let the history
feature be disabled... and/or an option to limit a number of saved
events in the history by some number (per application will be great).
50 and 500 MB have the difference, it would be better to leave that
memory for windows to use as system cache :-)
Brian Dunnington
of memory when there are a lot of items in the History. i have already
started re-writing how the History is managed to keep the memory usage
from growing, as well as implementing an option to disable history
altogether (though it probably wont be in the UI or per-application -
it will probably end up only being a configuration setting that has to
be manually set, but nothing is set in stone yet).
these changes will hopefully be in the next bigger release (i am
considering doing a very small release this week to fix a specific bug
with TCP socket handling, but these changes wont be included in that).
>
> You received this message because you are subscribed to the Google Groups "growl for windows" group.
> To post to this group, send email to growl-fo...@googlegroups.com.
> To unsubscribe from this group, send email to growl-for-wind...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/growl-for-windows?hl=en.
>
>
>
Laurent Somers
I am uninstalling Growl and its plugins. I am grateful, but
disappointed.
I really liked the idea but my expectation was that having one
'gateway' for notifications, I would see less combined memory usage
than having notifications for each app. Sadly, that doesn't seem the
case and I just don't have the RAM to spare:
Growl: 104MB
gmailgrowlworker: 23MB
gmailgrowl: 8 MB
growlextras.itunesplugin.exe: 22 MB
I'd like to see SQLite used for history and other data, and a very
limited amount of data in memory. SQLite is fast and wouldn't be a
bottleneck.
The plugins seem to me too big as well. I'd like to see sub-Megabyte
size, but maybe that's not an option with C#/.NET?
I might try it again though - when I get my 8 GB RAM computer :)
All the best
Laurent
On Dec 15, 6:26 pm, Brian Dunnington <briandunning...@gmail.com>
wrote:
Michael Letterle
Brian Dunnington
Thanks for sharing your reasons for removing Growl.
The memory usage of the app itself is definitely something i am
working on. the History is the biggest offender, and probably the
easiest fix, but there are other optimizations that can be made as
well and it is a high priority on the list of things to do.
As for the plugins, that is something that is out of my control. i
would love it if all apps built Growl support in natively so that no
plugins were needed at all, but that will take time and right now, the
plugins and helper apps are the next best thing. plugins and helper
apps dont have to be written in C# - they actually have to be written
in whatever language their hosting app requires (for example, Winamp
and Pidgin require C++ plugings). for apps that do use a .NET-based
plugin, there is definitely a memory overhead penalty. i think that
even the simplest of .NET apps will require several MB of memory just
to load up. a few MB here and there is nothing to some people, but
quite a lot to others, and there are always trade-offs.
Again, thanks for taking the time to share your thoughts and I hope
that I can improve GfW enough that you will consider giving it another
try in the future.
Brian Dunnington
History is already persisted to disk, so they do not need to reside in
memory as well. of course, when the History tab is being viewed, the
items are inserted into a ListView which uses memory, but, if nothing
else, the items could be unloaded and the memory reclaimed when the
History tab is not visible.
beyond the History, the entire GfW UI remains in memory even when the
app is minimized to the tray. what i would like to see is the UI
completely decoupled from the service-related logic (listening for
notifications, routing to displays, etc) so that when the app is
running, most of the time there is only the minimum amount of overhead
being used (the .NET runtime will always use some amount of memory
even if no UI elements are loaded, but that is the cost of doing
business). when the UI is opened, additional memory will be used to
render it, but then can be quickly reclaimed when the UI is closed
again, unlike now.
Andrew Gearhart
Brian Dunnington
<andrew....@gmail.com> wrote:
> *this* is what I desperately want out of GFW. It would be fantastic to be
> able to run the "service" logic as you stated it.... as a service. Early
> problems with services surrounded the idea of getting the service to run as
> the right user. This isn't the case anymore and I'd love to see Growl
> running as a service which can have the GUI called to configure that
> service. I have taken no looks into the code of GFW... but I can't imagine
> that it would use much memory at all ... if it had essentially no operating
> UI on a regular basis. Even if the displays were cached/loaded somehow to
> improve display speed (if it was needed)... that would be great.
> Sign me up for the alpha on that! I'd love to see it.
> ~Andrew
explore it some more. conceptually, it is exactly what i want as well,
but i still dont know how to handle some of the details. when the
machine boots up and no one has logged on yet, whose preferences
should be used (including passwords and forwarding rules). for
notifications that come in when no one is logged on and are configured
to be displayed with an on-screen display, should they just be ignored
(since they cant be displayed while at the login screen)? if anybody
has thoughts on how this would actually work, i would love to hear
them.
in the end, the idea of separating the service part of GfW from the UI
part is definitely going to happen. whether or not that means it
becomes an actual Windows Service or something else and how all the
details work is still up in the air.
Carey Bishop
Jason Plum
Carey,
I’m going to chime in a bit on what you’ve just put out there J
We’ve done some rather in depth discussion of the “enterprise” version of GfW, and the last roadblock really is the methodology of the destination user. There are some “easy” ways of figuring it out such as, say user GUID when the notifications are configured and sent, however not every application is going to be aware of this fact. Citrix/RDS/TS servers being a prime example of “who is this *actually* intended for being an issue! When we can use AD at the enterprise level to know who is logged in where, it becomes simple to direct the notification to the machine(s) that user is logged into, it leaves us with who else may also be on that machine. For applications on other platforms, how do we know who it was meant for? What if 3 people have their VS build sending growls back from on the same TS (I know, but an example!) In that instance we can relatively know who they belong to, but what of not-so-intelligent services that might be growling?
What happens when you have an Admin, a power user and a secretary all logged in to the same TS? The admin doesn’t want to know the phone is ringing, and the power user doesn’t need to know the firewall is catching someone trying to get to playboy.com!
The sender will almost definitely have to know who it belongs to? Scaling/management nightmare is what I see if we try to ensure that the central management knows the passwords, etc for each user across a domain.
Just a bunch of throw-it-out-there.. My heads too busy with server rebuilds!
Joel "Jaykul" Bennett
> A design such as this would also work on terminal servers or Citrix servers, where each user could run their own instance of the Growl UI, displaying their own choice of notifications, while the system administrators could control which notifications are received from and sent to remote servers.
I’m not sure that’s true. GNTP calls for a SPECIFIC port, so there can only be one listener per IP address. I’m sure it’s a failure of my imagination, but I can’t imagine how multiple users running Growl UI’s connected to a single growl “service” could work, without significant changes to the protocol. Growl (and GNTP) would have to account for what USER to send to, or every user would (be able to) get every notification.
I mean, how do you handle that even with *local* apps? It’s not just your dev tools, but your email client, IM client, etc. that are going to be sending notifications to this service – you need to be SURE that nobody else can receive those notices unless you intentionally forward them. Doing that would require new versions of … everything (not just Growl, but all the apps?) right?
--
Joel “Jaykul” Bennett
From: growl-fo...@googlegroups.com [mailto:growl-fo...@googlegroups.com] On Behalf Of Carey Bishop
Sent: Tuesday, December 15, 2009 10:55 PM
To: growl-fo...@googlegroups.com
Subject: Re: Memory Usage
Hi Brian,
My thoughts would be that the Windows service would be responsible for receiving, authenticating and forwarding notifications to other devices. The UI would then be responsible for showing notifications using the current user's selected display and with their selected sound effect, etc.
In effect, this would mean that passwords and forwarding rules would be machine-wide settings, while display and sound choices would be user-specific. It would also seem appropriate to use a user group (say "Growl Administrators") to determine which local users have permissions to change the passwords and forwarding rules, rather than restricting it solely to administrators of the local machine.
A further step would be to split the password and forwarding lists up between machine-specific and user-specific, where the Windows service would accept notifications using any of the machine passwords or any of the user passwords of the currently logged on users, and forward notifications to all of the machine-specific destinations and any of the destinations specified by the currently logged on users. This would add to the complexity considerably, but it would allow users to run their own applications with notifications hidden from other logged on users on the local machine, while still allowing administrators to receive and forward certain system and monitoring notifications when there are no logged on users.
Carey Bishop
Carey Bishop
Jason Plum
The problem as I see it is simple, at least for me: what happens when a notification is meant for multiple people across multiple machines? Does the originating service have to keep track of ~50 peoples’ location and passwords?
Brian Dunnington
well-known port and then forwarding received notifications to
individual user instances over internally configured ports was
discussed when the GNTP spec was being hashed out. in the end, it was
decided that this was an implementation detail really. for OSes that
dont support multiple users logged on at the same time, they could
just implement the listener/displayer as a single app. for platforms
that wanted to handle simultaneous users, it would be up to them to do
it behind the scenes. the well-known port would be the only visible
interface, but the implementation could route those notifications
however it deemed appropriate. as a way of helping those scenarios, a
user-target header was proposed (something like Target-User:
Workgroup\Brian) that could serve as a hint as to where the
notification was intended.
however, in practice, it puts additional burden on the sending apps.
now they have to know who the notification is for (and have a way to
reliably know who is logged on), as opposed to all current
implementation where the app just sends the notification (usually to
the local computer) and it is handled automagically. requiring the
sending app to know (and care) which user the notification is for
opens up a whole new can of worms.
as more and more people have multi-user situations, this will become a
bigger need, but so far, there is no great solution as to how to make
it work across all platforms easily, which is the driving goal behind
GNTP. (there were lots of ideas like making Target-User an optional
header for backwards compatibility as such, but like others pointed
out, getting another user's email notifications or whatever is not
desirable and it creates the possibility of having
confusing/inconsistent behavior).
as i see it, there are three main reasons for wanting GfW to run in a
service-like manner: 1) to decouple the UI for performance reasons, 2)
to allow forwarding to Prowl/email/etc even when the machine is not
logged on, and 3) to send notifications to multiple users on the same
machine.
#1 is on the roadmap either way. even if GfW stays as a user
executable, the prefs UI and the actual server portion will be
separated out, so that will be taken care of.
#2 is the reason i hear most often, and conceptually, i agree.
however, this is somewhat of a niche case. a large portion of the
normal prefs (display style, duration, sticky, etc) wont even apply to
a non-logged on workstation. and the forwarding at that point could
only apply to a single user anyway (as Joel pointed out - you wouldnt
want another user's email forwarded to your iphone, etc), so building
in a special case that works in ways not typical of how GfW normally
works feels funny. if leaving a machine logged in is the actual
problem, then maybe there are other solutions to the problem
(Enterprise GfW comes to mind*).
#3 has never actually been brought up as an actual real-world use
case, but it would conceptually be nice to figure out. we have to keep
in mind that 99% of GfW users are regular people who want on-screen
notifications when they are logged on as the only user of their
computer. any other solution has to keep that simplicity in mind.
i actually appreciate all of the discussion around this topic because
it is one that requires quite a bit of forethought to get right.
hopefully the thoughts and ideas keep coming in and we can try to
understand the root problems and then figure out how to best address
them.
* Enterprise GfW would be a service that ran regardless of anyone
being logged in, just like any other server. when a user logs on and
used the prefs UI to configure it, it would be like configuring IIS or
Exchange or anything else - you are configuring the server/service
only, not user-level prefs. individual users would still have their
own personal prefs that they can set, similar to a browser or mail
client. in theory, a home user could run the Enterprise *service* and
the UI *client* on the same machine to achieve what is being discussed
in this thread without impacting normal, non-server users.
Joel Bennett
would have to change how it sends messages. As far as I know, the only
time passwords are being used in Growl right NOW is when you forward
messages from growl on one machine to growl on another. I don't think
I even have that enabled.
I'm not saying don't do it -- just pointing out that it's not
something Growl for Windows can implement unilaterally, and it won't
be backwards compatible.
--
Joel
Joel Bennett
<briandu...@gmail.com> wrote:
...
> however, in practice, it puts additional burden on the sending apps.
> now they have to know who the notification is for (and have a way to
> reliably know who is logged on), as opposed to all current
> implementation where the app just sends the notification (usually to
> the local computer) and it is handled automagically. requiring the
> sending app to know (and care) which user the notification is for
> opens up a whole new can of worms.
Yeah. That's what I was trying to say :-P
It would work great if everything was being "forwarded" to that
machine (because you'd have per-user passwords), but not otherwise.
> as i see it, there are three main reasons for wanting GfW to run in a
> service-like manner: 1) to decouple the UI for performance reasons, 2)
> to allow forwarding to Prowl/email/etc even when the machine is not
> logged on, and 3) to send notifications to multiple users on the same
> machine.
I would totally embrace #3 being the "Enterprise" version. It's very
much not the "normal user" use case. And if you did that, I think it
would be perfectly safe to say: we assume that if you're not running
the enterprise version that you're the only user and all messages sent
to the machine will be shown to whoever's logged on (bearing in mind
passwords for remote messages, and forwarding rules, etc).
It would be nice if multiple users sharing a machine (not
simultaneously) had separate passwords for remote messages, and the
back end could store ones that didn't decrypt with the active user's
password (and/or process them as it would when nobody was logged in).
--
Joel
Brian Dunnington
> much not the "normal user" use case. And if you did that, I think it
> would be perfectly safe to say: we assume that if you're not running
> the enterprise version that you're the only user and all messages sent
> to the machine will be shown to whoever's logged on (bearing in mind
> passwords for remote messages, and forwarding rules, etc).
i am leaning this way too.
A) single user or multiple non-simultaneous users (ie: regular joes) =
normal GfW
B) multiple simultaneous users, citrix/terminal services, non-logged
in workstation, etc = enterprise GfW
> It would be nice if multiple users sharing a machine (not
> simultaneously) had separate passwords for remote messages, and the
> back end could store ones that didn't decrypt with the active user's
> password (and/or process them as it would when nobody was logged in).
right now, all passwords (and all user prefs including forwarding
rules and application/notification prefs) are stored and applied
per-user, so that should work today. the only thing it does not do is
store invalid notifications for later use. this is because 1) there
might not even be another user to process them later (the password is
just wrong), and 2) Growl is more of a real-time notification system.
getting notified the next time you log on that some things happened
yesterday is not really what it is intended for.
Joel Bennett
<briandu...@gmail.com> wrote:
> right now, all passwords (and all user prefs including forwarding
> rules and application/notification prefs) are stored and applied
> per-user, so that should work today. the only thing it does not do is
> store invalid notifications for later use. this is because 1) there
> might not even be another user to process them later (the password is
> just wrong), and 2) Growl is more of a real-time notification system.
> getting notified the next time you log on that some things happened
> yesterday is not really what it is intended for.
True enough, and yet ... you have a history and an offline mode ;-)
--
Joel
Brian Dunnington
=) i know. i thought about that as i wrote it and knew i wouldnt get
it past anyone, but i figured i would give it a shot anyway.
Carey Bishop
Jason Plum
I agree that passwords *could* be pushed by AD, or GPO, etc (some modification to the AD schema possibly necessary for that?), but then how to manage to know which workstations that these messages should be sent to? Seems a centralized service would be needed and/or queryable for locating destination users.