Arkadiy Vertleyb wrote:
OTOH, writing a primitive optimizer, would, in our opinion do more harm than good.
By "harm" do you mean have worse performance?
Yes, and also (possibly) inability to handle more complicated cases.
Well I certainly agree that a library that couldn't handle complicated cases, or whose performance was poor, would need a rethink. But I don't think RML is in that category. It has excellent performance and can handle very complex queries. I should exercise caution however - I await to see how well your library copes with 1000000 items, does a self-join, adds another 1000000 items and does a second self join. You sound fairly confident that you will beat me! If you like you can come up with an extremely complex query - and we can compare again.
If you're going to make claims about the performance of an approach, then you need to have benchmarks. You can't argue about air. For example the RML benchmarks
http://visula.org/relational/benchmarks.html
show RML to be matching or outperforming std::map.
Would you care to benchmark your RTL versus RML or the STL before making such claims? I think that would settle which approach did more "harm".
Note that I didn't say RML's approach is harmful. All I said is that a simplistic approach to implementing optimizer is IMO inacceptable. Are you saying your optimizer is simplistic? :-)
Of course not!
I believe that talks about performance are premature. I think it's time to talk about what can and what can't be done with this libraries. Then comes the optimization.
I don't think talking about performance is premature. If we are going to provide a practical library, then performance matters. If a user has a choice between using RTL in a real application, but it is 10 times slower than Boost.MultiIndex, then I expect most users would stick with Boost.MultiIndex. People need to know. On the other hand, I believe that RML is a much easier and more efficient (than std:: containers) way to manage collections. But I am biassed :-)
As for benchmarks, for such simple case as yours, you don't need RTL -- you can benchmark sorted std::vector or Boost.Multi_index. The performance of RTL will not be different, since it's based on these containers. To outperform STL is definitely not one of RTL's tasks.
For more complicated cases though, such as ones that I described in my original post, RTL does provide an efficient, index-based solution, while other libraries, AFAIK, don't.
In that case, could you give an example where RTL would be efficient, while "other libraries" would be inefficient. I have a case for you that might not be so efficient in RTL: What about indexing on multiple columns? This is what RML is designed for, otherwise you may as well just use std::map. Although it sounds a little competitive, I think it's pretty instructive to be able to compare different implementations. Regards, Calum