Interesting, the problem from my previous post (about 7!:0) does not occur in Jcon, only in Jgtk.
Back to my original post, using Jconsole: 7!:0'' 7108608 load 'addons/gui/jgtkgrid/test/mygrid.ijs' 7!:0'' 7108608 It seems, when using the console, that J itself does not report a leak. However, Windows Task Manager still does. Do you think this an error in the reporting in Task Manager, or is the leak still occurring, and J is not reporting it? Justin On Thu, Aug 4, 2011 at 11:09 AM, bill lam <[email protected]> wrote: > My experience with gtkide is limited, For comparison there is no such leak > in > jconsole. Could you test jgtkgrid under jconsole? > > > Чтв, 04 Авг 2011, Justin Tirrell писал(а): > > Sorry it took so long to get back. I have been trying to use 7!:0 to > report > > memory and more accurately reproduce the leak. However, in the process I > > found this: > > > > 7!:0 '' > > 10480768 > > 7!:0 '' > > 10486144 > > 7!:0 '' > > 10491520 > > 7!:0 '' > > 10496896 > > 7!:0 '' > > 10502272 > > > > The memory usage seems to rise by 5376 every time I run 7!:0. This only > > occurs in J701, not J602. I'm new to J, but it seems this would > > unintentionally skew results. Can anyone shed some light on this? > > > > Thanks, > > Justin > > > > > > > > On Mon, Aug 1, 2011 at 2:28 PM, L.Tomei <[email protected]> > wrote: > > > > > > > > As Bill noticed, probably GtkTreeView and GtkListStore are not designed > > > to hold tens of thousands of rows. > > > So, it's normal that J engine is often faster in data processing, than > GTK > > > in data representation. > > > Unfortunately GTK has not a true "spreadsheet" widget, suitable for > grids. > > > When I started developing jgtkgrid, I've tried to use the GtkSheet > widget > > > available in the gtkextra package (http://gtkextra.sourceforge.net/), > but > > > my code was very unstable and I had to leave this idea. > > > Anyway, let me know how I can reproduce the bug you have found > > > about memory usage, so I can try to fix it. > > > > > > Lorenzo > > > > > > > > > Justin Tirrell wrote: > > > > > > > > Thanks for the tips. I ran a test using 7!:0 and mygrid.ijs. I found > that > > > > the used memory consistently rises by 5248 every time after the first > run > > > > (the first run uses 6144). > > > > > > > > I would be nervous about using an experimental port, but I will check > it > > > > out; it may be great for my purposes. Thanks. > > > > > > > > > > > > On Fri, Jul 29, 2011 at 9:12 PM, bill lam <[email protected]> > wrote: > > > > > > > >> I have only very limited experience with jgtkgrid. In general > windows > > > >> task > > > >> manager counts all memory used by dll called from j.exe, A more > > > >> conclusive > > > >> way is to use 7!:0 to report actual memory used from J memory > manager. > > > >> > > > >> I guess the GTKTreeStore cannot handle or was designed to handle > tens > > > >> of thousands of rows. > > > >> > > > >> There is an experimental port of J6 grid to J7. It has not been > released > > > >> to > > > >> pacman and has to be checkout form JAL public svn. It is slower > than > > > >> that > > > >> in J6 but may be faster than jgtkgrid for large amount of data. > > > >> > > > >> Птн, 29 Июл 2011, Justin Tirrell писал(а): > > > >> > I've found a possible memory leak issue in J7 with Jgtkgrid. If > you > > > run > > > >> a > > > >> > script that uses grid several times and watch J's memory usage, I > > > >> noticed > > > >> > that closing the gtk window does not seem to free the memory it > used. > > > >> I > > > >> > used the test script addons/gui/jgtkgrid/test/mygrid.ijs and > Windows > > > >> Task > > > >> > Manager to watch memory. Can anyone confirm this? > > > >> > > > > >> > This normally would not be a big deal, but a script I wrote > queries a > > > >> > database of about 120,000 rows and outputs to a new grid each > time. > > > >> This > > > >> > often results in large amounts of memory being leaked on each run, > > > >> which > > > >> > adds up over time. > > > >> > > > > >> > > > > >> > As a separate issue, filling a grid with a large amount of data is > > > very > > > >> > slow, far slower than the database query itself. In J6, this > would be > > > >> a > > > >> > perfect place to use virtual grid. This feature has yet to be > > > >> implemented > > > >> in > > > >> > J7, though, and my script is almost unusable with large datasets > > > >> because > > > >> of > > > >> > this. Most queries I'll be doing will be relatively small, but on > the > > > >> > chance that a query returns a very large dataset, the program will > > > >> either > > > >> > crash or just take a very long time to display the grid data. Any > > > >> ideas > > > >> or > > > >> > thoughts on this? > > > >> > > > > >> > Thanks, > > > >> > Justin > > > >> > > ---------------------------------------------------------------------- > > > >> > For information about J forums see > > > http://www.jsoftware.com/forums.htm > > > >> > > > >> -- > > > >> regards, > > > >> ==================================================== > > > >> GPG key 1024D/4434BAB3 2008-08-24 > > > >> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > > > >> > ---------------------------------------------------------------------- > > > >> For information about J forums see > http://www.jsoftware.com/forums.htm > > > > > ---------------------------------------------------------------------- > > > > For information about J forums see > http://www.jsoftware.com/forums.htm > > > > > > > > > > -- > > > View this message in context: > > > > http://old.nabble.com/Re%3A-Possible-jgtkgrid-bug-and-issue-with-large-grids-in-J7-tp32171649s24193p32172107.html > > > Sent from the J Programming mailing list archive at Nabble.com. > > > > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
