From boris.smilga at gmail.com Sat May 2 13:31:16 2009 From: boris.smilga at gmail.com (Boris Smilga) Date: Sat, 2 May 2009 17:31:16 +0400 Subject: [cl-json-devel] cl-json 0.4 In-Reply-To: <609F04D1-9D2B-4419-8900-848B70BA21CB@gmail.com> References: <42946560-CE15-4C06-B872-CBC74E070395@gmail.com> <50e8e4f60904140253q6d10df55g9785e598cfea3664@mail.gmail.com> <590f36270904150955m4f68c676gaa1131b26836c45c@mail.gmail.com> <590f36270904210229u3f80eb3m1b82cb4ec15202e2@mail.gmail.com> <50e8e4f60904271448q6b9d1fcdjdd8ec75296ba63f4@mail.gmail.com> <609F04D1-9D2B-4419-8900-848B70BA21CB@gmail.com> Message-ID: <590f36270905020631i59a7b9ber16aaa5193de01951@mail.gmail.com> On Wed, Apr 29, 2009 at 5:28 AM, Boris Smilga wrote: > It is more complex than just an old bug having been fixed: if I am not > mistaken, that particular piece of behaviour in SBCL showed a difference > between Darwin/PPC and FreeBSD/Intel, rather than a difference between > versions. I am now trying to upgrade SBCL from 1.0.18 to 1.0.23 on the > former platform, and, as soon as it is up, I will post a more informed > follow-up on the issue. Positive on that. In 1.0.23 under Darwin, I have (EXPT 10.0 444) => #.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY; in 1.0.22 under FreeBSD, the same signals a FLOATING-POINT-OVERFLOW. It is an architecture issue rather than a version issue (and, for that matter, a known one?see https://bugs.launchpad.net/sbcl/+bug/309069). > Well, I have worked on the two versions with a profiler, and I think there > is still much room for improvement. ?If you look into the table attached > [...] , you would be able to see two > most outstanding foci of regression: the string reader and the camel-case > converter. [...] ?The regression in the former, > however, is completely gratuitious. ?I cannot quite see, at this moment, > what the cause is, but, by all means, this thing should be brought back into > the bounds of decency. Two things here: 1) READ-JSON-CHARS (more exactly, its helper READ-CHARS-UNTIL) in 0.3 used what can be called a ?string-stream accumulator? to collect the decoded characters, by running (WITH-OUTPUT-TO-STREAM (OSTR) ... (WRITE-CHAR (FUNCALL CHAR-CONVERTER ...) OSTR)). It is much faster than vector or even list accumulation. 2) The escaped character lookup can be compiled from alist to a (CASE ...) construction by using a little metaprogramming trick. This gains some cycles. I have tried to fix this, and it got me down to 90% regression on FreeBSD/i386 (SBCL 1.0.27), 65% on Darwin/PPC (SBCL 1.0.22). Not so bad as before, if I dare say. Henrik: would you also try it out in your setup? I have also added a subsection on CLOS decoder security to the manual. Please find the patches attached. Sincerely, - B. Smilga. -------------- next part -------------- A non-text attachment was scrubbed... Name: ssaccum-etc.dpatch Type: application/octet-stream Size: 28032 bytes Desc: not available URL: From henrik at evahjelte.com Sun May 3 08:50:54 2009 From: henrik at evahjelte.com (Henrik Hjelte) Date: Sun, 3 May 2009 10:50:54 +0200 Subject: [cl-json-devel] cl-json 0.4 In-Reply-To: <590f36270905020631i59a7b9ber16aaa5193de01951@mail.gmail.com> References: <42946560-CE15-4C06-B872-CBC74E070395@gmail.com> <50e8e4f60904140253q6d10df55g9785e598cfea3664@mail.gmail.com> <590f36270904150955m4f68c676gaa1131b26836c45c@mail.gmail.com> <590f36270904210229u3f80eb3m1b82cb4ec15202e2@mail.gmail.com> <50e8e4f60904271448q6b9d1fcdjdd8ec75296ba63f4@mail.gmail.com> <609F04D1-9D2B-4419-8900-848B70BA21CB@gmail.com> <590f36270905020631i59a7b9ber16aaa5193de01951@mail.gmail.com> Message-ID: <50e8e4f60905030150h8bcdb63s4c141159c3089419@mail.gmail.com> On Sat, May 2, 2009 at 3:31 PM, Boris Smilga wrote: > On Wed, Apr 29, 2009 at 5:28 AM, Boris Smilga wrote: > > I have tried to fix this, and it got me down to 90% regression on > FreeBSD/i386 (SBCL 1.0.27), 65% on Darwin/PPC (SBCL 1.0.22). ?Not so > bad as before, if I dare say. ?Henrik: would you also try it out in > your setup? > > I have also added a subsection on CLOS decoder security to the manual. > ?Please find the patches attached. Applied. I haven't looked deeply, but I just ran the performance-decoder test and it took 1.4 to 1.7 secs vs. the old version 0.7 secs. My suggestion is that we release the new version as 0.4 but write in the docs somewhere that the 0.3 version can be used for situations where performance is very important. Thanks, Henrik From henrik at evahjelte.com Mon May 25 21:33:07 2009 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 25 May 2009 23:33:07 +0200 Subject: [cl-json-devel] cl-json 0.4.0 Message-ID: <50e8e4f60905251433s4ad61130k9fad4bfa13886437@mail.gmail.com> A new release of CL-JSON packed with new features is now available, thanks to Boris Smilga and Hans H?bner. * Flexible CLOS decoder * Greatly improved flexibility in customizing both the decoder and encoder. * Various other improvements * Backwards compatible * Good supply of testcases * Precise documentation (online) http://common-lisp.net/project/cl-json Big thanks to Boris! Enjoy, Henrik Hjelte