lablgtk missing macros to live in harmony with the garbage collector
Felix Ruess <[email protected]> Tue, 27 Jan 2015 19:52:50 +0100
| Newsgroups | gmane.comp.lang.ocaml.lib.gtk |
|---|---|
| Message-ID | <CAEc+GFe56dATzks_dSFmESb4PoGZqb6NgoZ4wVF4a1CH=Rti7w@mail.gmail.com> |
--===============1419856751560806405== Content-Type: multipart/alternative; boundary=047d7b874e08fab65b050da6c282 --047d7b874e08fab65b050da6c282 Content-Type: text/plain; charset=UTF-8 Hi guys, I noticed that our applications seem to use more and more memory the longer they run. Profiling it, it looks like most of it is coming from closures that use GObj and GtkSignal. It looks like most parts of lablgtk don't properly use the CAMLparam, CAMLreturn, etc macros that are described here: http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html#sec440 Fixing a similar issue in some of our code interfacing with C made a HUGE difference. E.g. the ml_g_signal_override_class_closure function in ml_gobject.c does not use these macros... Any particular reason for that? Am I missing something here, or is that a bug (or rather lots of bugs)? Cheers, Felix --047d7b874e08fab65b050da6c282 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div><div><div><div><div>Hi guys,<br><br></div>I= noticed that our applications seem to use more and more memory the longer = they run.<br></div>Profiling it, it looks like most of it is coming from cl= osures that use GObj and GtkSignal.<br><br></div>It looks like most parts o= f lablgtk don't properly use the CAMLparam, CAMLreturn, etc macros that= are described here: <a href=3D"http://caml.inria.fr/pub/docs/manual-ocaml/= intfc.html#sec440">http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html#se= c440</a><br></div>Fixing a similar issue in some of our code interfacing wi= th C made a HUGE difference.<br><br></div>E.g. the ml_g_signal_override_cla= ss_closure function in ml_gobject.c does not use these macros...<br></div>A= ny particular reason for that? Am I missing something here, or is that a bu= g (or rather lots of bugs)?<br><br></div>Cheers, Felix<br></div> --047d7b874e08fab65b050da6c282-- --===============1419856751560806405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Lablgtk-list mailing list [email protected] https://lists.ocamlcore.org/cgi-bin/listinfo/lablgtk-list --===============1419856751560806405==--