Is your feature request related to a problem? Please describe.
Your library implements an excellent fast floating-point to string conversion algorithm (based on the Schubfach algorithm). This conversion is used internally in the JSON writer but is not exposed as a standalone public API.
Sometimes One may just want to output a float-point as fast as possible, for
example in log for other custom output format, but cannot use yyjson's dtoa
algorithm, although has imported yyjson to deal with json.
I think the more basic API may also useful not just in json scenarios.
Describe the solution you'd like
May simply wraper the write_f64_raw private function, as follow:
// caller provide buffer at least 40 bytes
char *yyjson_dtoa(double val, char *buf)
{
if (!buf) return NULL;
u64 raw;
memcpy(&raw, &val, sizeof(raw));
u8 *end = write_f64_raw(buf, raw, YYJSON_WRITE_ALLOW_INF_AND_NAN);
return (char *)end;
}
Optionally, I also noticed that yyjson has many flags and macros to control
some read/write behaviors, is it wroth expose another API like
yyjson_dtoa_ops ?
Describe alternatives you've considered
Expose one or several private API is almost zero overhead for existing users.
But if exposing a new function is not desirable, consider documenting the existing internal functions so that users who understand the trade-offs can use them directly.
Additional context
In my practical project, I mainly use the read(parsing) part of yyjson, but
less use the write part. Actually I developed another lightweight library to
construct json string from scratch without dom. For json with most string or
integer element, my solution can be easily optimized to become faster than
yyjson since eliminate dom overhead. But for json with almost float-point
number, my solution is slower than yyjson. I also have tried to use other
algorithm from some open source project such as fmt and rapidjson for double
serialization, it's still slower than yyjson(with dom overhead).
Then I test use the yyjson_dtoa like above wrapper to serialize a json array
of double number, my solution reported about 5-10% faster than yyjson,that
can be considered as dom overhead.
For now, I don't want to copy the dtao implementation from yyjson, because it
is a bit heavy for me, and I don't think have any revolution improvement on it.
And more, since I also use yyjson library, it seams silly to extract and copy
the dtoa method alone, and waste the duplicated 10k+ cache table.
Although I only need the high performance dtoa algorithm from yyjson, but
for consistence API consideration on basic conversion, it's suggested to
also expose some other APIs:
- yyjson_dtoa: write double to string (the started proposal)
- yyjson_atod: read string as double
- yyjson_itoa: write int64 to string
- yyjson_atoi: read string as int64
- yyjson_utoa: write uint64 to string
- yyjson_atou: read string as uint64
and maybe string escape also worth standalone usage:
- yyjson_escape: escape special char in string
- yyjson_unescape: unescape special char in string
Is your feature request related to a problem? Please describe.
Your library implements an excellent fast floating-point to string conversion algorithm (based on the Schubfach algorithm). This conversion is used internally in the JSON writer but is not exposed as a standalone public API.
Sometimes One may just want to output a float-point as fast as possible, for
example in log for other custom output format, but cannot use yyjson's dtoa
algorithm, although has imported yyjson to deal with json.
I think the more basic API may also useful not just in json scenarios.
Describe the solution you'd like
May simply wraper the
write_f64_rawprivate function, as follow:Optionally, I also noticed that yyjson has many flags and macros to control
some read/write behaviors, is it wroth expose another API like
yyjson_dtoa_ops?Describe alternatives you've considered
Expose one or several private API is almost zero overhead for existing users.
But if exposing a new function is not desirable, consider documenting the existing internal functions so that users who understand the trade-offs can use them directly.
Additional context
In my practical project, I mainly use the read(parsing) part of yyjson, but
less use the write part. Actually I developed another lightweight library to
construct json string from scratch without dom. For json with most string or
integer element, my solution can be easily optimized to become faster than
yyjson since eliminate dom overhead. But for json with almost float-point
number, my solution is slower than yyjson. I also have tried to use other
algorithm from some open source project such as fmt and rapidjson for double
serialization, it's still slower than yyjson(with dom overhead).
Then I test use the
yyjson_dtoalike above wrapper to serialize a json arrayof double number, my solution reported about 5-10% faster than yyjson,that
can be considered as dom overhead.
For now, I don't want to copy the dtao implementation from yyjson, because it
is a bit heavy for me, and I don't think have any revolution improvement on it.
And more, since I also use yyjson library, it seams silly to extract and copy
the dtoa method alone, and waste the duplicated 10k+ cache table.
Although I only need the high performance
dtoaalgorithm from yyjson, butfor consistence API consideration on basic conversion, it's suggested to
also expose some other APIs:
and maybe string escape also worth standalone usage: