The verbs input_jfe_ and output_jfe_ are run by the J engine. And anything done by those verbs calling other J names are part of the J memory while preparing to pass the input and output between J and gtk or jhs.
On Thu, Aug 4, 2011 at 5:47 PM, bill lam <[email protected]> wrote: > Then there should be no memory link in J. Windows task manager will count > memory used by dll, so the memory leak is external to J engine. I have no > idea how to debug memory leak in dll. > > Чтв, 04 Авг 2011, Justin Tirrell писал(а): > > 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 > > -- > 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
