more efficient handling for smalls strings inside json_object
smalls strings inside json_objects had a high overhead because dynamic
memory allocation was needed for each of them. This also meant that the
pointer needed to be updated. This is now changed so that small strings
can directly be stored inside the json_object. Note that on the regular
64 bit machines a pointer takes 8 bytes. So even without increasing
memory, we could store string up to 7 bytes directly inside the object.
The max size is configurable. I have selected up to 31 bytes (which
means a buffer of 32 including the NUL byte). This brings a 24-bytes
memory overhead, but I consider that still useful because the memory
allocator usually also has quite some overhead (16 bytes) for
dyn alloced memory blocks. In any case, the max buffer size can be
tweaked via #define.
These items were used for statistics tracking, but no code at all
exists to consume them. By removing them we save
a) space
because they counters required space, and did so in each and every
json object
b) performance
because calloc() needs to write less data and the counters are
no longer maintained; cache performance can be better, load
on OS main memory is lighter
We could conditionally enable/disable these counters, but I have not
done this they were really nowhere used and it looked more like a
left-over from the import of hashtable code.
This also adds a new API json_global_set_string_hash() which permits
to select the hash function. The default one is the only one that was
previously present. So there are no changes to existing apps, and the
new hash function needs to be explicitely be opted in. Especially for
smaller strings, the perllike functions seems to be around twice as
fast as the other one, with similarly good results in value distribution.
In certain C libraries (e.g uClibc), isnan() and related functions are
implemented in libm, so json-c needs to link against it. This commit
therefore adds an AC_TRY_LINK() test to check whether a program
calling isnan() can be properly linked with no special flags. If not,
we assume linking against libm is needed.
The json-c.pc.in file is also adjusted so that in the case of static
linking against json-c, -lm is also used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Alexander Dahl [Thu, 21 Aug 2014 13:42:50 +0000 (15:42 +0200)]
add bsearch for arrays
Arrays can already be sorted with json_object_array_sort() which uses
qsort() of the standard C library. This adds a counterpart using the
bsearch() from C.
Move the json_min() and json_max() macros to json_util.h and mark everything else in bits.h deprecated.
Eliminate all uses of bits.h within the json-c code.
Check for failures when allocating memory; return NULL and set errno=ENOMEM in a few of those cases.
Thanks to Susant Sahani for pointing out some of these.
Remove the old libjson.so name compatibility support. The library is only created as libjson-c.so now and headers are only installed into the ${prefix}/json-c directory.
Keith Derrick [Tue, 1 Oct 2013 16:18:51 +0000 (09:18 -0700)]
Avoid potential overflow in json_object_get_double
sscanf is always a potential problem when converting numeric
values as it does not correctly handle over- and underflow
(or at least gives no indication that it has done so).
This change converts json_object_get_double() to use strtod()
according to CERT guidelines.
Add a check for the -Bsymbolic-functions linker flag
The -Bsymbolic-functions linker flag reduces the amount of PLT jumps in
a shared object, and has a side effect of preventing symbol collisions
in libraries and applications linking against two different shared
objects exposing the same symbol.
While the former is (generally) a performance win, the latter is less
rare than expected. For instance, PulseAudio started linking against
json-c a while ago; now, every project linking against PulseAudio is
leaking json-c symbols. In the GNOME platform, this means that projects
linking against PulseAudio cannot be safely linked against other
libraries depending on the GLib-based JSON parsing libraries JSON-GLib,
because of a symbol conflict. Nominally, this conflict would not be an
issue: libraries and applications do not need to depend on two different
JSON parsing libraries; the symbol leakage, though, ends up causing
either segmentation faults, or weird errors. For further reference,
please see: https://bugzilla.gnome.org/show_bug.cgi?id=703734
JSON-GLib already switched to using -Bsymbolic-functions, but it would
be safe if json-c did the same, wherever the linker flag is available.
Added a json_object_new_double_s() convenience function to allow an exact string representation of a double to be specified when creating the object and use it in json_tokener_parse_ex() so a re-serialized object more exactly matches the input.
Add json_object_free_userdata() and json_object_userdata_to_json_string() too.
projects / json-c / log