On Tue, Apr 9, 2024 at 11:09 PM Rodion Efremov <codero...@gmail.com> wrote: > > Hello, > > Fair enough. However, why we have CursorableLinkedList and > NodeCachingLinkedList around when my previous benchmarking showed that they > are inferior compated to both TreeList and IndexedLinkedList?
We have a lot of things we don't need and that shouldn't be used. It happens sometimes on long lived bazaar-style projects without a clear vision and maintainer. If those two classes are demonstrably inferior, it might be worthwhile deprecating them. Meanwhile I'd prefer not to make the situation worse. We already have more code than we can maintain, and are wasting a lot of dev cycles on idiosyncratic churn to no good end. > Also, note that TreeList requires 3 references, 2 ints and 2 booleans per > node. IndexedLinkedList requires only 3 references per node. > > If you need benchmarking on small lists, just tell me and I will arrange > that. Lies, damned lies, and benchmarks. :-) Benchmarking is hard and rarely matches reality. By coincidence, I spent last week learning about the damage the TPCH benchmarks do in the database space. The benchmarks that matter are profiles of real world applications, and every application is different. Better algorithms are sometimes discovered, even for well trod territory like lists, but typically they only improve performance in the limit and often decrease performance in real world applications. Looking at the repo, this seems to be a newly constructed data structure. I suggest cleaning up the blog post and submitting it to an appropriate peer reviewed journal in the field and posting the preprint on arxiv so true experts can take a look. (I'm just a practitioner.) If the data structure proves out over time in real world use cases, then it should be considered for Apache Commons. However, I don't think Commons is the right place for bleeding edge research. -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
