From: Christian H. zu S. <ch...@tb...> - 2010-07-25 23:33:43
|
Thanks for taking a look at it. I have since 'darcs pull'ed the source and built it but do not see any change in residency. Below is the program; it has a residency of ~720MB. Btw, once in mainGUI, things do not get better. It seems that the gtk end doesn't clean up. Another thing I see is that the pixbuf's are not added to what GHC sees as memory in use. I guess that this can't be helped, but it is kind of funny that -sstderr thinks the program below requires just 3MB ;-) Gruss, Christian Last entry in repo: Tue Jul 20 09:01:51 CEST 2010 Axe...@in... * Add an option to the type generator to ignore the --destructor * command line spec. This allows e.g. Pixbufs to be GC'd immediatlely. Current test program: module Main where import Graphics.UI.Gtk import Graphics.UI.Gtk.Gdk.Pixbuf import Control.Monad import System.Mem main = do initGUI w <- windowNew pb <- pixbufNew ColorspaceRgb False 8 1000 1000 forM_ [1..10] $ \_ -> do forM_ [1..100] $ \_ -> do x <- pixbufScaleSimple pb 500 500 InterpNearest return () -- garbage collection, done after each major op performGC performGC onDestroy w mainQuit widgetShowAll w mainGUI * Axel Simon <Axe...@in...> [20.07.2010 09:05]: > Hi Christian, > > On 17.07.2010, at 01:54, Christian Höner zu Siederdissen wrote: > > >Hi, > > > >the program below displays a problem. 'pixbufScaleSimple' generates a > >new Pixbuf every time it is called (here a 100 times). But once out of > >scope, these instances are not garbage-collected. > > > >How do I get them to be? > > > > I've tried your example below but removed a 0 from every number > (where possible). > > I've then turned on the DEBUG flag in hsgthread.c which then spits > out information on when objects go out of scope: > > *Main> main > Loading package syb ... linking ... done. > Loading package array-0.2.0.0 ... linking ... done. > Loading package containers-0.2.0.1 ... linking ... done. > Loading package bytestring-0.9.1.4 ... linking ... done. > Loading package mtl-1.1.0.2 ... linking ... done. > Loading package filepath-1.1.0.2 ... linking ... done. > Loading package old-locale-1.0.0.1 ... linking ... done. > Loading package old-time-1.0.0.2 ... linking ... done. > Loading package unix-2.3.2.0 ... linking ... done. > Loading package directory-1.0.0.3 ... linking ... done. > Loading package process-1.0.1.1 ... linking ... done. > Loading package random-1.0.0.1 ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package glib-0.11.0 ... linking ... done. > Loading package gio-0.11.0 ... linking ... done. > Loading package cairo-0.11.0 ... linking ... done. > Loading package pretty-1.0.1.0 ... linking ... done. > Loading package pango-0.11.0 ... linking ... done. > Loading package gtk-0.11.0 ... linking ... done. > gtk2hs_threads_initialise: threads_initialised=0, > g_thread_get_initialized=0 > acquiring lock to add a GtkWindow object at 5795008 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GtkWindow object! > creating finalizer list. > releasing lock to add a GtkWindow object at 5795008 > acquiring lock to add a GdkPixbuf object at 5794de0 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5794de0 > acquiring lock to add a GdkPixbuf object at 5794e18 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5794e18 > acquiring lock to add a GdkPixbuf object at 5794e50 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5794e50 > acquiring lock to add a GdkPixbuf object at 5794e88 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5794e88 > acquiring lock to add a GdkPixbuf object at 5794ec0 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5794ec0 > acquiring lock to add a GdkPixbuf object at 5794ef8 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5794ef8 > acquiring lock to add a GdkPixbuf object at 5794f30 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5794f30 > acquiring lock to add a GdkPixbuf object at 5794f68 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5794f68 > acquiring lock to add a GdkPixbuf object at 5794fa0 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5794fa0 > acquiring lock to add a GdkPixbuf object at 5ac0010 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5ac0010 > acquiring lock to add a GdkPixbuf object at 5ac0048 > value of lock function is 90f93b4c > within mutex: adding finalizer to a GdkPixbuf object! > releasing lock to add a GdkPixbuf object at 5ac0048 > acquiring lock to kill objects > running 12 finalizers! > releasing lock to kill objects > > So your Pixbufs are enqueued correctly. However, we only free > objects when > mainGUI is called. We do this because some objects hold X11 > resources or Win32 resources and must be collected from the main GUI > thread (otherwise bad things will happen). In case of Pixbuf, this > is a bit unfortunate since they are retained until mainGUI although > they could be freed immediately. > > >Or, what I actually want: how to write an ImageViewer that loads > >lots of > >images? pixbufNewFromFile shows the same problem, but the program is > >larger ;-) > > > > I've enhanced our code generation for types that is used to specify > which constructor is used for a given object. I've then set the > Pixbuf related objects to use the default destructor that destroys > the objects immediately during GC (and not in the mainGUI loop). > With this patch your pixbufs will be GC'd as soon as they go out of > scope and GC runs. > > Cheers, > Axel > > >Many thanks, > >Christian > > > > > >module Main where > > > >import Graphics.UI.Gtk > >import Graphics.UI.Gtk.Gdk.Pixbuf > >import Control.Monad > > > >main = do > > initGUI > > > > w <- windowNew > > > > pb <- pixbufNew ColorspaceRgb False 8 1000 1000 > > > > forM_ [1..100] $ \_ -> do > > pixbufScaleSimple pb 1000 1000 InterpNearest > > return () > > > > onDestroy w mainQuit > > widgetShowAll w > > mainGUI > > > >------------------------------------------------------------------------------ > >This SF.net email is sponsored by Sprint > >What will you do first with EVO, the first 4G phone? > >Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________ > >Gtk2hs-users mailing list > >Gtk...@li... > >https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > |