2013/12/10 Chris Pearce <cpea...@mozilla.com> > It seems to me that we should be optimizing for developer productivity > first, and use profiling tools to find code that needs to be optimized. > > i.e. we should be able to use STL containers where we need basic ADTs in > day-to-day coding, and if instances of these containers show up in profiles > then we should look at moving indivdual instances over to more optimized > data structures. > > > On 12/11/2013 4:42 AM, Benjamin Smedberg wrote: > >> njn already mentioned the memory-reporting issue. >> > > We already have this problem with third party libraries that we use. We > should work towards having a port of the STL that uses our memory > reporters, so that we can solve this everywhere, and influence the size of > generated code for these templates.
I agree with the above. I would also like to underline an advantage of the STL's design: the API is very consistent across containers, which allows to most easily switch containers (e.g. switch between map and unordered_map) and recompile. This has sometimes been derided as a footgun as one can unintentionally use a container with an algorithm that isn't efficient with it. But this also has a really nice, important effect: that one can avoid worrying too early about optimization details, such as whether a binary tree is efficient enough for a given use case or whether a hash table is needed instead. By contrast, our current Mozilla containers have each their own API and no equivalent of the STL's iterators, so code using one container becomes "married" to it. I believe that this circumstance is why optimization details have been brought up IMHO prematurely in this thread, needlessly complicating this conversation. 2013/12/10 Robert O'Callahan <rob...@ocallahan.org> > Keep in mind that proliferation of different types for the same > functionality hurts developer productivity in various ways, especially when > they have quite different APIs. That's the main reason I'm not excited > about widespread usage of a lot of new (to us) container types. > For the same reason as described above, I believe that adopting STL containers is the solution, not the problem! The STL shows how to design containers that have a sufficiently similar API that, in most cases where that makes sense (e.g. between a map and an unordered_map), you can switch containers without having to adapt to a different API. Benoit _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
