[cl-json-devel] cl-json 0.4

Boris Smilga boris.smilga at gmail.com
Sat May 2 13:31:16 UTC 2009


On Wed, Apr 29, 2009 at 5:28 AM, Boris Smilga <boris.smilga at gmail.com> 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: <https://mailman.common-lisp.net/pipermail/cl-json-devel/attachments/20090502/0ebd5290/attachment.obj>


More information about the cl-json-devel mailing list