
Carlos, I'm wondering whether using the launcher prompt may be the reason for xmonad starting at 4 to 5 megs freshly and climbing to around 7 megs. I didn't try without the launcher promot and don't really complain but am curious whether there's some caching and possible space leak in either the launcher prompt or xmonad core or one of the popular action hooks. Gwern, this is not an objection to merging, just an observation. This is on ghc-7.6.1-i386. Any comments?

Hello Carsten, After I started the launcher prompt and did some queries, the resident memory shown in `top` went from 5620 bytes in a restarted xmonad to 6440 bytes. After doing more queries it stopped at 7280 bytes. I observed the same behavior with the shell prompt (Prompt.Shell), but I am not sure if it is due to the new patch. Could someone that doesn't have the patch applied that a look? If the new patch is the reason, the guilty data type might be XPOperationMode in XPState:
data XPOperationMode = XPSingleMode ComplFunction XPType | XPMultipleModes (W.Stack XPType)
where
data XPType = forall p . XPrompt p => XPT p type ComplFunction = String -> IO [String]
I am not sure what should I do to get the XPState garbage collected
when a window prompt is destroyed. Help?
cheers
2012/9/19 Carsten Mattner
Carlos,
I'm wondering whether using the launcher prompt may be the reason for xmonad starting at 4 to 5 megs freshly and climbing to around 7 megs. I didn't try without the launcher promot and don't really complain but am curious whether there's some caching and possible space leak in either the launcher prompt or xmonad core or one of the popular action hooks.
Gwern, this is not an objection to merging, just an observation.
This is on ghc-7.6.1-i386.
Any comments?
participants (2)
-
Carlos López Camey
-
Carsten Mattner