fast_obj VS dragonbox

The operations you're talking about with the example of loading 3d data is the realm of parsing, and there's a LOT of theory available and a LOT of code available for how to implement things -- there are TONS of options. Since you don't know where to start you should investigate parsing generally in C. I highly recommend you take a look at an existing library in C that loads 3d data, like this library https://github.com/thisistherk/fast_obj/blob/master/fast_obj.h that deals with OBJ the format.

I've replaced tinyobjloader with fast_obj which speeds up model loading process significantly. Here is a good article comparing different obj loaders.

I wanted to say try writing your own like I did, then I remember I made it in c++ with string & stringstream std lib :(. I don't know how much would it take you to write it yourself, might try it myself. After a quick search I think this one has a pure c version: https://github.com/thisistherk/fast_obj

Oh I see. I was talking about writing a program in the language of your choice that does this, it's not very difficult. If you use C or C++ you can load the file with https://github.com/thisistherk/fast_obj to make it even easier.

Apparently exact minimal float-to-string conversion is more recent than I thought, and many languages used to print more (Python?) or less (PHP) decimal digits than necessary to uniquely identify the bit pattern. Python correctly prints 46000.80 + 553.04 as 46553.840000000004, but I don't know if it ever prints more digits than needed. One recent algorithm for printing floats exactly is https://github.com/ulfjack/ryu, though I'm unaware what's the state-of-the-art (https://github.com/jk-jeon/dragonbox claims to be a benchmark and the best algorithm).

A recent update to fmt was posted to r/cpp 3 days ago (https://www.reddit.com/r/cpp/comments/vrxkt0/fmt_90_released_with_improvements_to_floating/), and since that's still fresh on people's minds, they'll wonder how yours compares; and they'll probably wonder how it compares in terms of precision, round trip-ability, and performance of DragonBox https://github.com/jk-jeon/dragonbox. By "they", I probably mean "me" :D.

Existing fast and correct float-to-string implementations are out there. Just use them: https://github.com/jk-jeon/dragonbox. Or maybe use your stdlib if it has good support

Parse floats faster with dragonbox

Even if what you say is true, it makes little sense to not reuse it. There are other concerns here and one of them is code size. But to address the performance issue, fmtlib is doing under 50ns for most fp numbers via dragonbox(https://github.com/jk-jeon/dragonbox has the chart). So still cpu bound, but all FP output is CPU bound. At this point, what prices are we trading for faster?

There are some benchmarks in https://github.com/jk-jeon/dragonbox#performance. TL;DR it's faster than other state of the art algorithms like Ryu, Schubfach and variations of Grisu. We saw a nice speed up when switching from Grisu3 to Dragonbox in {fmt}: https://github.com/fmtlib/fmt/pull/1882 and it has been improved even more since then.