I don’t know if you are interested in some other open source projects that parse JSON, but have you looked at the decoder here?
https://github.com/vstakhov/libucl <https://github.com/vstakhov/libucl> It can parse more than just the JSON format - but it has some JSON benchmarks attached and works really well - and is plain C. > Am 14.12.2014 um 20:38 schrieb Jakub Zelenka <bu...@php.net>: > > Hi, > > On Wed, Dec 10, 2014 at 6:43 AM, Remi Collet <r...@fedoraproject.org> wrote: >> >> >> The main issue is the "non-free" decoder. >> >> > Agreed. > > >> Of course perf can be considered as an issue (I think minor). >> jsonc have bad perf, but is free. >> >> If jsond have nearly same perf than old one, it's enough. > > > My initial benchmarks (for PHP5 jsond ext) actually shows better > performance for json instances containing strings. Pure int and floats are > more or less the same. But need more benchmarks to confirm that. > > >>> Just a quick update on jsond. The decoder is mostly done. >> >> So, please go on > > > I have ported a decoder to PHP 7. The code can be found on my github > php-src jsond branch ( for code changes see > https://github.com/bukka/php-src/compare/jsond ). It's just a replaced > decoder. The encoder is the same though. All tests are passing for me... I > haven't done any perf tests as yet. There is a big room for improvements > but it's a good start IMHO. > > I'll have more time during Christmas so I would like to improve the code > and do some benchmarks. Think we could have RFC around New Year... > > >> >>> I have been recently working on optimization for the encoder. I >>> already have over 30% speed improvement in encoding for string >>> based arrays/objects like $_SERVER. It's generally much faster now >>> but there is still a big room for other impromevents. I also >>> experiment with a new buffer (replacement for smart_str in json >>> encoder). It needs lots of optimization but it already gives better >>> numbers for some cases. However it also gives worse numbers for >>> some other cases like processing small integers so I need to play >>> with it a bit more. As I said before I need a better set of >>> benchmarks to be sure that it works fine for a big number of json >>> instances. >> >> Current encoder is not an issue. >> Perf. can be manage later. >> >> And I don't think we should use another string management for json >> encoder, so if improvment is possible, should go in smart_str. >> >> > Yeah I won't go there (replacing smart_str). It's still experimental and it > would delay the whole thing quite a lot. I'll rather add just few proven > improvements that are already done in jsond and that are not breaking ABI. > > Cheers > > Jakub
