https://bz.apache.org/bugzilla/show_bug.cgi?id=66209
--- Comment #8 from John Engebretson <jeng...@amazon.com> --- Sure - looking at the specific code in https://github.com/FastFilter/xorfilter/blob/master/xorfilter.go vs https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/webresources/JarContents.java, the Bloom filter uses two hashes and two bitwise lookups; the Xor filter uses three hashes and three reduce operations. Two hashes vs three is an implementation detail but the extra work of the reduces, although small, may come down to the number of instructions required. I don't have the expertise to address that point, but at a minimum there are more method calls and any associated overhead. As I reread the code though, I notice that the current JarContents code uses a fixed-length array of bits, and the Xor filter uses a variable length array of uint8. Fixed vs. variable length can be addressed, but bit vs uint8 certainly does. For a given number of buckets, the JarContents implementation will therefore be far smaller in memory. I think? However, this conversation isn't tied to the bug/feature/behavior about memory cleanup. Might be interesting to chase this separately as an enhancement. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
