I've been thinking of creating a file format called J-ON. The simplest version is to go from a J noun to a serialized string state: lr=: 3 : '5!:5 <''y''' lr noun
and the reverse is: ". lr noun enhancements to the simple version could include the following security features: encode to base84 or so, with the encoding characters being the only primitives allowed to represent a noun being "allowed"... an unencoded string would decode to only allowed characters. remove quotes for strings that are intended to be variable names. Disallow trailing _ in names in order to prevent a J-ON object from representing cross locale variables. With that security feature it is possible to use kv data as an ini file, loading and assigning to variables within your program's chosen locale, with the full possibility of J's noun contents. My questions for doing so are whether lr or ". have some size limitations. On your 219k character file, what are the timings for lr thatnoun and ". thatlr ? ----- Original Message ----- From: Raul Miller <[email protected]> To: Programming forum <[email protected]> Cc: Sent: Tuesday, October 15, 2013 1:01:29 PM Subject: Re: [Jprogramming] performance and deeply nested boxes Oh, great, on this mac, the key sequence I use to paste text will also in at least one context send the message. Anyways, picking up where I left off: On Tue, Oct 15, 2013 at 12:55 PM, Raul Miller <[email protected]> wrote: > I just now used the json parsing code at > http://rosettacode.org/wiki/JSON#J on a moderately sized json string > (219003 characters). > > Here's what space and time look like for this effort: 16.1096 5.26771e6 That seems excessively slow. I think the speed loss has to do with the way boxing is managed. The result has a depth of six. I've seen similar performance problems when I've tried to use J parsing other data from foreign contexts. (For example, parsing bethesda games .nif files.) I've considered other representations (like using locales as objects to represent what I'm using a box to represent), but that winds up with object counts in the millions, and the manual memory management required with locales makes this approach scary. I might as well be working in some other language, for all that J offers me here. But Arthur Whitney's K/Q has a tree structure that is almost like J's boxing mechanism and allegedly it has good performance. And then there's https://github.com/kevinlawler/kona So I'm wondering if perhaps we could improve J's implementation here? But I'm not focussed enough on this issue to say how that would work. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
