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
