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
