Re: [MLton] cost of _export
Bernard Berthomieu <[email protected]> Mon, 08 Dec 2014 22:42:56 +0100
| Newsgroups | gmane.comp.lang.ml.mlton.devel |
|---|---|
| Message-ID | <[email protected]> |
Great ! Many thanks Matthew for your swift answer and the patch. Your links clearly explain the issues involved when calling SML from C. I will try the patch asap and let you know the improvements on my use case. For the record, the actual SML application is an xml parser relying on libexpat (in C) but with start/end element handlers implemented in SML. So it exactly fits the "SML calling C calling SML" scenario the patch improves. Thanks again for your help, Bernard. On 12/8/14 8:50 PM, Matthew Fluet wrote: > On Fri, Dec 5, 2014 at 10:57 AM, Bernard Berthomieu <[email protected]> wrote: >> The actual application may call SML from C that many times or even more. >> Can somebody explain me the reason for the amount of bytes allocated; >> where does it come from ? > The short answer is that each call of an _export-ed SML function > results in a new ML thread being created to service the call. > However, it is possible to cache a worker thread to service the calls > of _export-ed functions, so that in the common case of no deep mutual > calls between SML and C only a single new ML thread is created. Read > more at: https://github.com/MatthewFluet/mlton/commit/97c2bdf. With > that patch applied, for your example application, I get: > > [mtf@fenrir tmp]$ ./x @MLton gc-summary -- 1000000 > done > GC type time ms number bytes bytes/sec > ------------- ------- ------- --------------- --------------- > copying 0 0 0 - > mark-compact 0 0 0 - > minor 0 0 0 - > total time: 121 ms > total GC time: 0 ms (0.0%) > max pause time: 0 ms > total bytes allocated: 22,312 bytes > max bytes live: 0 bytes > max heap size: 122,880 bytes > max stack size: 624 bytes > num cards marked: 0 > bytes scanned: 0 bytes > bytes hash consed: 0 bytes > > You should be able to apply that patch to the most recent MLton > release without issues. If you rebuild from that commit, then for > your example application, you will need to change > let val sum = _import "C_add" private : int * int -> int; > to > let val sum = _import "C_add" runtime private : int * int -> int; > in order to indicate that the _import-ed function is actually a > reentrant function (read more at: > https://github.com/MLton/mlton/issues/88). > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > MLton-devel mailing list > [email protected]; [email protected] > https://lists.sourceforge.net/lists/listinfo/mlton-devel > ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk