MarceloHByte

Done! Nice results and one more lib with clear results in validation test. Thanks @Vincent Parrett.

Nice! I'll process it tomorrow.

I probably didn't redo the tests with Delphi versions 10.2 up to 11.3. I'll explain why: using the CE version, the updates were forced, but I still have the executable for each version. In short: System.JSON with Delphi 10.1 has total average time equals to 1546.8 ms (images/Github-03-C-System.JSON.png). Now, version 12.1 it has total average time equals to 431.2 ms (images/Test-Speed-DX-12.1-CE-System.JSON.png). Improvement = 3.6 times faster. That's why I agree with Stefan Glienke's statement that the improvement occurred between versions 10.2 and 10.3. Sorry if I created false hopes between 11 and 12.

Thanks for the update. In my tests, I only checked the performance gain between versions 11 and 12, although I've started with Delphi 10 CE. I'am investigating the memory leak issue with JDO and what I found is that TLibJDO.Destroy is not being called in the finally part of TFormMain.RunTest. Maybe it has something to do with my use of TInterfacedObject.

I'm using Delphi 12.1 CE.

Sorry, I got confused in the previous comments. By the way, Hausladen is a very skilled developer and JsonDataObjects unit tests are well-constructed, so I'm really suspicious of my code. I'll try to create an isolated example following the structure that I use in TestJSON to try to capture the leaking and then submit to him. On the other hand, the fact that JDO now has clean Validation test may mean that Andy has been looking at my work. 😉

Maybe these removals explain memory leaking. I think my code is simple enough to not touch delicate parts in terms of overflow, but it is important to mention I'm a C++Builder developer. If you see any bad usage of JsonDataObject, or any other case, please let me know.

I've just updated JsonDataObjects as a Git Submodule. We have a new champion, but it is leaking memory. The Validation test now is clear.

Just confirming, System.JSON had a performance gain (3 times faster) in Delphi version 12, but I haven't researched the reasons.

This is just a guide. Combining Speed, Validation, and Open File tests can help with some selection processes. Ultimately, the idea is to simply bring the options together in one place, with some kind of demonstration. And let's not forget, it's cool to see that this small project motivated improvements coming from such an experienced developer.

This wasn't overlooked. Some solutions, like the one I developed (McJSON), have a method like "HasKey()." For those who don't need to test for duplication, you can add directly using regular "Add()." But I agree that not all solutions have direct features for this. I always rely on user experience to apply TestJSON for further testing and decision-making. However, many only consider the "race" effect of this work.

Your diagnosis is correct and also comes close to the other test that was recently added to achieve a similar analysis to your critique. Please see the "Open File" tests.

Your diagnosis is correct and also comes close to the other test that was recently added to achieve a similar analysis to your critique. Please see the "Open File" tests.

I'm having trouble testing with PasJSON (https://github.com/BeRo1985/pasjson). A small case throws an exception of memory violation when using Stringfy(). Does anyone have a usage example where we create some key:value pairs and then get a JSON string from the entire object?

Thanks for the heads up. The version I tested is older than the current one. I'll try to update it using Submodules in Git.

Hi, I've added mORMot version 2 and pasjson is on its way. https://github.com/hydrobyte/TestJSON Marcelo.

Hi All, Just trying to help here. I have same error message trying to compile ZeosLib version 8 with C++Builder 12.0 for Win64 platform. With Win32 I had no problem. About this message complaint telling you to remove units, I would recommend to uncheck the "ICS" item into "Install Packages" dialog from "Components > Install Packages..." menu before installing your packages. I think this ilink64 error is related with object files produced by Delphi Compiler and then linked with C++Builder ilink64.