I just finished some benchmarking work using Solr's benchmark module. It should be pretty easy to tweak an existing benchmark to try both. Purely from a maintainability standpoint, we could make a hard break decision in Solr 10.
On Mon, Aug 5, 2024 at 1:00 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > > My hunch is that Jackson would be more performant than Noggit, but I > don't have any hard numbers to back that up so it's just an educated > guess. I swear there was some other issue that gave Noggit vs. > Jackson numbers but I can't find it now. SOLR-16691 (where Noble > switched at least some things over to using Jackson) mentions perf > improvements in the issue description but doesn't quantify those. > Maybe someone else with context can chime in with data? > > Personally, I'd rather see us use Jackson across the board. I'm sure > we can write and maintain great serialization code if we want to spend > that effort, but do we? Ultimately we're here for Search - it's hard > to imagine us wanting to spend anywhere near the amount of time on > serde code that a project like Jackson does as their raison d'etre. > > The Noggit lenient parsing *is* really nice for making requests by > hand, but that's a minority use case. If there's evidence that > Jackson is faster, is it worth slowing down 99% of JSON requests just > so that we can leniently parse the 0.1% of malformed reqs that need > it? Is it worth the cost of maintaining our own JSON parsing code in > perpetuity? > > Best, > > Jason > > On Mon, Aug 5, 2024 at 11:54 AM David Smiley <dsmi...@apache.org> wrote: > > > > We have a couple JSON Parsing libraries -- "Noggit" (internal to Solr) > > and "Jackson". Noggit is more lenient in parsing. I suppose Solr > > should use Noggit for parsing JSON coming into it, but AFAIK Solr only > > returns/emits valid JSON; yes? For parsing JSON that we assume is > > compliant (e.g. from Solr), should we prefer Jackson or Noggit? Are > > there performance advantages? > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
