<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 17, 2018 at 8:15 AM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> writes:<br>
<br>
> That was my misunderstanding. Sorry for the false alarm.<br>
><br>
> That said, I don't think this patch makes much sense. There's no theory<br>
> behind it to explain why this could make things faster (it shouldn't as<br>
> long as the hash function generates evenly distributed hash value). I think<br>
> what we should do is<br>
><br>
> 1. first, verify that our bloom filter is really correct by taking a look<br>
> at the output binary carefully, because even if the bloom filter is wrong,<br>
> that doesn't cause any correctness issue, but instead it just makes things<br>
> slower, and then<br>
<br>
</span>I don't think that is correct in general. Consider a bloom filter of all<br>
0s. With that the dynamic linker would not try to lookup any symbol in<br>
that dso.<br></blockquote><div><br></div><div>Ahh, that's right.  If we set too many bits, that just makes things slower even though everything works fine (modulo speed difference), but if we correctly set at most two bits per symbol, that wouldn't happen.</div></div></div></div>