Hi Matthijs,
thank you for accepting the patches. In these days we finalize a
migration of our nameservers from Bind9 to NSD. There are still some
problems with NSD for domain service providers like us, but Bind9 has
its own problems too -- and I really like the clean and simple design of
NSD :-). I send our remarks and suggestions to the list as soon as our
nameservers will be successfully switched to NSD. (And maybe more
patches, I have at least two now -- one that disables xfrd daemon and
the other that aggregates bind8 stats over all server processes.)
Best regards
Martin
Matthijs Mekking napsal(a):> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Martin,
>
> I have looked at your patches and they look good. Here is what I did
> with them:
>
> - - I have applied the b64_pton patch without modification.
>
> - - I have made the mmap patch configurable. You can enable it at build
> time, with --enable-mmap. I have marked it experimental. By default off.
>
> - - I have applied the parse-token-leaks patch the way it is.
>
> - - I did not do the adaptive-rrtype-lookup patch. It changes lookup
> behavior in favor of frequently used rrtypes. However, it's not clear
to
> me if this benefit the future lookups in all cases. In some cases it
> might perform worse (for example zones sorted on rrtype).
>
> The applied patches are now in trunk. Before releasing, they will
> undergo another round of reviewing.
>
> Thank you very much for your effort!
>
> Best regards,
>
> Matthijs
>
> Martin Svec wrote:
>
>> Hi Matthijs, Paul,
>>
>> I send you two more patches that slightly improve zonec performance.
>>
>> (a) parse-token-leaks.patch -- avoids unused calls of region_strdup and
>> zoctet in parse_token. I believe it also fixes a memory leak in zonec.
>>
>> (b) adaptive-rrtype-lookup.patch -- tries to improve O(n) complexity of
>> rrtype_destriptor_by_name(). Because I didn't want to rewrite
>> rrtype_descriptors table from scratch, I added another table containing
>> pointers to named rrtype_descriptors. In this table, frequently used rr
>> types are automatically moved forward, which reduces the overall number
>> of strcasecmp comparisons.
>>
>> The patches are public domain, without any guarantees ;-) They improve
>> compilation time by few percents, depending on the contents of zone
files.
>>
>> Unfortunately, I see no more room for (micro)optimizations in zonec.
>> With all my patches, the profile looks as follows:
>>
>> 32.96% zonec /usr/sbin/zonec [.] yylex
>> 9.19% zonec /usr/sbin/zonec [.] yyparse
>> 6.35% zonec /usr/sbin/zonec [.] label_compare
>> 4.76% zonec /usr/sbin/zonec [.] write_data_crc
>> 3.55% zonec /usr/sbin/zonec [.] b64_pton
>> 3.47% zonec /usr/sbin/zonec [.] parse_token
>> 3.24% zonec /lib64/libc-2.10.1.so [.] memcpy
>> 2.49% zonec /usr/sbin/zonec [.] dname_compare
>> 2.33% zonec /lib64/libc-2.10.1.so [.] __strcasecmp
>> 1.98% zonec /lib64/libc-2.10.1.so [.] _IO_file_xsputn
>> 1.86% zonec /lib64/libc-2.10.1.so [.] _IO_fwrite
>>
>> Yylex seems to be a great candidate for optimization, but most of its
>> time is spent in the innermost loop generated by lex. The same holds
for
>> yyparse. And the other functions are below 6%...
>>
>> Best regards
>> Martin
>>
>>
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQEcBAEBAgAGBQJLs1ZhAAoJEA8yVCPsQCW5/5gH/0Oa8kUgIk7C+c7pA29c6r6o
> 5zkChsyX83dVwfnPhtvvOdbbk1rG/RRuiTBYtMRnmyrPZmueXJ/O+8rIO/MdLv1n
> YeHXQaus7aPdb58c9r+rZy0tpbFqow2V1Zj03io7RdFsDIYCfUFnh1E2ap9DUF1/
> zMOD2+S/KvhIJASTg20+2YMBzVfqhA3TGj/VnG5MFqbab0/cUnfXLz8CMyM3WNF2
> HsvTfub3DWvtUzpBAy8md6v+xnNIz4JSdxl80rht0NhSzx4HbTk491/9JhUem46c
> Wf3YX/4WUduAtoVSDGFB2ZKV+Z6xgZoZXnmUDwnCuRYpVEEnsP5/zDWsuraljqA> =G56M
> -----END PGP SIGNATURE-----
>