GNU bug report logs - #20154
25.0.50; json-encode-string is too slow for large strings

Previous Next

Full log

Message #139 received at 20154 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 20154 <at> debbugs.gnu.org
Subject: Re: bug#20154: 25.0.50;
 json-encode-string is too slow for large strings
Date: Mon, 20 Apr 2015 19:11:05 -0400

On Tue, 21 Apr 2015 01:41:54 +0300 Dmitry Gutov <dgutov <at> yandex.ru> wrote: 

DG> On 04/21/2015 01:20 AM, Ted Zlatanov wrote:
>> Absolutely, implementing it ourselves is dumb. Because it's been *done
>> already* many times, in libjson in particular.

DG> Is libjson available on all our target platforms?

I think it's available on the free ones, but I'm not positive about
*all* of them. It's under the GPL, in any case, and I think in 2015 we
can safely assume any platform of strategic interest to the GNU project
will have it.  Do you know of any counterexamples?

Besides the relatively large performance gains from libjson, please
don't disregard the significant work already sunk into making sure it is
bug-free.

>> I think all the time and effort spent on that would be better spent on
>> the FFI work, which would also enable libyaml integration and many other
>> improvements.

DG> A faster `replace-regexp-in-string' could also mean a slight speed
DG> improvement in many different places. And that project would be like
DG> two orders of magnitude simpler than FFI.

I didn't say it wouldn't be simpler to do things as this thread proposes.

I am also not saying improvements in `replace-regexp-in-string' are a
waste of time. I am specifically talking about making them for the sake
of speeding up the encoding of JSON data.

Ted

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.