Leaderboard

Need more precision than Single and Double can provide? Then maybe this will help: https://blog.grijjy.com/2021/05/05/high-precision/

@Remy Lebeau Selective perception? If a compiler is not a critical product function I don't know what is.

I have attached a spreadsheet I created a couple of years ago, comparing DD and QD to Single and Double, as well as to some well-known arbitrary precision libraries. Results may be a bit different now if I would run these tests again, but I think will still be in the same ballpark. In short, DD is 2-10 times slower than Double, but 5-100 times faster than other arbitrary precision libraries using the same precision. Likewise, QD is 4-100 times slower than Double, but 5-250 times faster than other libraries. You can also do some simple benchmarking by running the included Mandelbrot sample at different levels of precision (for a magnification level that works at Double precision). Since this library directly uses the QD C++ library, it has the same limitations (such as thread safety). Although I would assume that most operations would be thread safe since as long as you don't mutate the same DD/QD value from multiple threads. But I haven't checked the C++ source code for this, so I am not sure. MultiPrecisionSpeed.xlsx

@Dany Marmur Agreed - it's the job of runtime library developers to get the most out of their data structures and algorithms so the users of those libraries don't have to worry 99.9% of the time but just chose the reasonable type/algo for the job. Funny enough I am currently in the process to do exactly that for my library and can tell you that for the RTL it's certainly not the case, unfortunately.

Well, Delphi's floating point library isn't threadsafe so they can have a party together!!

If I understand correctly nobody likes to be forced to pay for bugfixes for stuff they already bought.

Yes. That would also solve issues for people using trial version, bumping into some problem and then not having the ability to properly test trial version because they cannot install patch. I seriously cannot imagine buying something if I cannot properly test it. If I am already Delphi user and I want to upgrade, then maybe but in such cases I already have some other reasons for upgrading.

First, do some debugging and find out if the record "disappears" on the server side (query, or in the JSON transformation), or on the client side (store raw JSON, review contents...).

Here is benchmark code, but have in mind it might be a bit complicated because it is a start of my testing a common table lookup implementation (see posts above): https://pastebin.com/itBRv76X TSynDictionary (SynCommons.pas): https://github.com/synopse/mORMot

As David wrote, mORMot has a 3 license - if you use MPL it is very commercial-project-friendly. TL&LR: Nothing to pay, just mention somewhere in your software that you used it, and publish any modification you may do to the source code. Another article worth looking at: https://www.delphitools.info/2015/03/17/long-strings-hash-vs-sorted-vs-unsorted/ It depends what you expect. Also note that for long strings, hashing may have a cost - this is why we implemented https://blog.synopse.info/?post/2021/02/12/New-AesNiHash-for-mORMot-2

You can license mormot under MPL which is fine for use in a commercial product.