Re: REST impact paper

It was thus said that the Great J. Andrew Rogers once stated:
> 
> On Sep 8, 2017, at 10:10 PM, Sean Conner <[email protected]> wrote:
> > 
> >  So what magic things were done to make JSON parsing faster with
> > proprietary code than with open source code?  Or alternatively, what does
> > open source do wrong?  I'm asking for specific examples and not a
> > generalized "it sucks" argument.
>  
> For JSON specifically, I needed to parse trillions of documents as quickly
> as possible, so performance was rarely satisfactory in any case. Because
> “open source”, we could inspect the architecture and implementation for
> ways to improve performance. Being software performance junkies, we find
> many opportunities to materially improve throughput, some algorithmic and
> some architectural.

  And I'm sure there are assumptions you made writing that code that open
source, meant to be used who knows where, can't make.  One probably being
that 95% of all JSON blobs being parsed are below a certain size so you can
optimize for that.  Or that they only have a certain nesting level.  It also
sounds like you did not write a drop-in replacement but had to rewrite the
code to handle the new JSON parser.

  Question:  how many of the tests presented here:

	http://seriot.ch/parsing_json.html

would your high performance, proprietary JSON parser pass?

  Also, how easy is it to use for a small project?  There are plenty of JSON
parsers that are easy to use for non-critical needs.

> Open source projects will often only accept patches for a subset of
> algorithmic optimizations, rejecting some because they violate some other
> aesthetic or goal of the project (e.g. it is an anti-optimization for some
> obscure or archaic hardware). Architectural optimizations are effectively
> a non-starter for an existing open source project even when it would be
> hugely beneficial (e.g. PostgreSQL). 

  For PostgreSQL, that would be an I/O scehduler, right?  Or perhaps direct
disk I/O?  The engineering resources might be beyond the scope of what
PostgreSQL can handle.  Oracle can do such things because they can hire
enough engineers to handle the different operating systems they support---it
wouldn't surprise me if a majority of the code in Oracle can't be shared
among versions.

  (Then there might be operating system limitations---Linus Tovalds, for
instance, doesn't think highly of direct disk I/O, so Linux doesn't have
great (or any) support for that.  Good luck fixing that)

> We ended up implementing our own highly-optimized JSON parser written in
> C++11. It was much faster than the open source ones it replaced. Nothing
> fancy, just tight engineering that prioritized performance. We went back
> later and reimplemented certain hot paths in assembly using SSE4 for
> systems that supported it, for another 2.5x improvement in throughput as I
> recall.

  Yes, a typical work flow.  At work, we use an open source product for SMS
(Kannel).  It works (no comment on the code since I'm not an expert in SMS)
but it does way more than we want.  Yes, we wrote our own replacement but
mainly to simplify the setup (performance isn't an issue simply because of
the rate limitations placed uon us by the various Monopolistic Phone
Companies).  

> The lack of attention to operational cost in open source is no less of a
> problem than the lack of attention to user interface design. Users care
> about these things a lot even if programmers tend not to.

  But ... but ... I thought companies *don't* care about operation costs,
because those who control a bigger budget get promoted and thus, there's no
inventive to cut costs (half joking here).

  -spc (I thought it was ease of maintenance that's important, because the
	ability to add features quickly means more money comes in ... )

_______________________________________________
FoRK mailing list
http://xent.com/mailman/listinfo/fork