Bug ID | 1201884 |
---|---|
Summary | Massive augeas slowdown with MALLOC_PERTURB_ |
Classification | openSUSE |
Product | openSUSE Tumbleweed |
Version | Current |
Hardware | Other |
OS | Other |
Status | NEW |
Severity | Normal |
Priority | P5 - None |
Component | YaST2 |
Assignee | jsikes@suse.com |
Reporter | fvogt@suse.com |
QA Contact | jsrain@suse.com |
CC | pm.mullaney@gmail.com, yast2-maintainers@suse.de |
Found By | --- |
Blocker | --- |
I reported this upstream: https://github.com/hercules-team/augeas/issues/768 During package builds and during development phase, openSUSE sets MALLOC_CHECK_=3 and MALLOC_PERTURB_=69 in the environment. This causes the glibc heap to be less "forgiving" to catch some bugs. However, the MALLOC_PERTURB_=69 setting, which causes glibc to explicitly fill newly allocated and freed memory with that value, has a massive negative effect on augeas performance. The testsuite actually runs more than 20x slower! Effectively, the package build takes >2000s instead of 99s because of this. FWICT, the bottleneck is that add_new_trans calls realloc very often, and glibc treats that like a new allocation + deallocation to be able to overwrite the old data. Maybe that can be optimized somehow? perf report shows: - 95,52% 0,00% augparse libaugeas.so.0.25.0 [.] typecheck typecheck typecheck_iter - ambig_iter_check - 94,70% ambig_check - fa_ambig_example - 84,24% expand_alphabet (inlined) - 84,23% fa_clone - 83,90% add_new_trans - mem_realloc_n - 83,88% __realloc (inlined) - _int_realloc - 83,87% _int_free __memset_avx2_unaligned_erms needinfo on glibc to confirm that the suspicion is true. Maybe we should just unset _MALLOC_PERTURB in augeas.spec's %check section?