I just added the creation of a second library (libpsl-inline) with a slightly different approach. A tool (psl2c) genrates C data structures from the PSL ASCII file. This file will be included by psl-inline.c to build libpsl- inline.so.
There also is an own include file and a seperate test. The API is similar to libpsl but needs not mallocs and the internal vector code is not needed any more. psl_inline_init(); psl_inline_is_public(domain); psl_inline_deinit(); The difference in CPU cycles is dramatic: $ valgrind --tool=callgrind ./test-is-public ==19426== I refs: 9,818,337 $ valgrind --tool=callgrind ./test-is-public ==19438== Collected : 167557 Going deeper with kcachegrind reveals that only ~30k cycles are consumed by psl_inline_init() + 10x psl_inline_is_public(). The caveat is of course the libraries size (stripped): -rwxr-xr-x 1 tim tim 8744 Mär 22 20:56 libpsl-0.1.so.0.0.0 -rwxr-xr-x 1 tim tim 423064 Mär 22 20:56 libpsl-inline-0.1.so.0.0.0 Also, is creating the library with every change to affected_tld_names.dat reasonable ? How often does it change ? I would still like to move the discussion to libpsl-bugs, but so far nobody is reading it ... (https://groups.google.com/forum/#!forum/libpsl-bugs/join) Tim
signature.asc
Description: This is a digitally signed message part.
