Michael, Internally JsonTools just stores the document as JSON fragments or text, in the case of object, array, or null, the text is empty, but in the case of number or bool, it converts the text to a number or bool when you ask AsNumber or AsBoolean. Now normally this wont be a problem because as you read a document you'll read a particular node possibly once as you hand it off to some other system, be it a database insert, a subroutine, or other use.
In practice what's happening is I am delaying the conversion until it's needed, which makes my parser faster when just parsing a document. If you need to use the node value as a number or a bool, then the cost of the conversion happens at that time, but if you don't need to use a particular field there is no conversion cost. This is one of the reasons my parser is faster. I still validate the number, bool, and other fields but I don't convert until needed. The downside, as you've seen is that converting the same value over and over again results in longer execution time. That said, if a user request every field as a number or bool once when processing an incoming request (say you are writing a REST service) then the performance would equal out and the speed difference would favor the faster parser. A side benefit of storing JSON fragments is that the node kind can be changed easily without the need to remove an item from an internal list, destroy the class, create a new one of a different class, apply a copy of the original name, and reinsert. Of course this lazy evaluation of numbers and boolean scould be improved by caching the conversion once calculated (e.g. StrToFloat) and reusing the conversion in any subsequent calls. For now I will keep it simple as is as I feel for most cases the user will either not need the conversion, or need it once, and the performance lost in invoking it many times wills be made up for in all the times the conversion is never used. 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. And so on...
-- _______________________________________________ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
