Re: [Lazarus] Tests results of several pascal based JSON parsers

[Marco van de Voort via lazarus]

Op 2019-08-30 om 10:18 schreef Anthony Walter via lazarus:
I've posted a new page that tests the speed and correctness of several 
pascal based JSON parsers.


https://www.getlazarus.org/json/tests/

In full disclosure I am the author of the new open source JsonTools 
library, and even though my parser seems to a big improvement over the 
other alternatives, my tests were not biased.


If anyone would like help in replication the tests, let me know and 
I'll see what I can do.


Also, to be thorough, you should read through both the article I 
posted at the top this message, and my original page 
 which has been updated with more 
information. Both pages took some time to write, and I promise if you 
read through them some of your questions will be answered without 
having to ask others for help or insight.


I only looked superficially, but I miss a test on a large files, only 
files of a few kb repeated 10 times.


The large file case is a good test for scaling of internal datastructures.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] [fpc-pascal] Tests results of several pascal based JSON parsers

[Michael Van Canneyt via lazarus]

On Sat, 31 Aug 2019, Anthony Walter via lazarus wrote:


Michael,


Real world examples of never used JSON fields:

Calling most web REST methods which return JSON as a web result where the
caller is only interested in success or failure with a message.
Acting as a RESTful service where many JSON request bodies use optional
values that are meant to be skipped.
Retrieving settings where and option is never used, yet stored, such as a
dockable or floating pallet position that is always left closed.


In my experience these are a minority of the scenarios. They look to me also 
as the scenarios where speed is largely irrelevant since the structures will be

small.

Most of the time I see code getting a result of a REST server and displaying the
result in a grid or inserting in a database. In these scenarios, all values
are always evaluated. lazy evaluation will not give you performance
improvements in such scenarios.

So use cases clearly vary, and as usual you should pick the technology that
is best suited for the job at hand.

For me the result of the whole discussion is that we've managed to
establish that fpjson is functioning correct (it triggered the discussion in
the first place), and I did some long-due speed improvements on fpjson. The
speed difference between a stream or string as a JSON source has also been
eliminated.

All in all a positive result.

Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus