I would say that just pulling the latest boost into the tree and using it for builds is the best path forward. But I'm in no way competent to make that kind of change in the build system -- especially during the automake cmake changeover period. Allen Samuels Software Architect, Fellow, Systems and Software Solutions 2880 Junction Avenue, San Jose, CA 95134 T: +1 408 801 7030| M: +1 408 780 6416 allen.samuels@xxxxxxxxxxx -----Original Message----- From: Casey Bodley [mailto:cbodley@xxxxxxxxxx] Sent: Wednesday, February 03, 2016 1:26 PM To: Matt Benjamin <mbenjamin@xxxxxxxxxx> Cc: Sage Weil <sweil@xxxxxxxxxx>; Allen Samuels <Allen.Samuels@xxxxxxxxxxx>; ceph-devel@xxxxxxxxxxxxxxx Subject: Re: inline vector container Hi Allen, I did spend some time a couple months ago experimenting with a custom allocator with inline storage for standard containers. You can find my branch on github at https://github.com/cbodley/ceph/commits/wip-preallocator. I was aiming for a general solution that worked with non-contiguous containers, but couldn't find a good way to handle deallocations. So the approach was really only a good fit for std::vector. I also had trouble getting it to do the right thing with the copy and move operators. I found that it was trying to use the new allocator to release memory that came from the old allocator. Presumably there's a way to make this work using std::allocator_traits; have you had better luck here? I'd love to see your prototype. I tend to agree that we should go with the boost solution if we can. But if a) we can't use boost::small_vector in the near-term due to versioning, and b) we can get a custom version tested and working, it might be worth pursuing. Casey ----- Original Message ----- > Hi, > > I think we should go with small_vector for this role, yes. I found > two issues. First, there are critical defects in small_vector prior > to boost 1.6.0. Second, though it is header-only, the coupling with > related version-specific boost types (container, allocator, respective > detail types, and platform-specific selectors...) seems to make > pulling it in separately pretty unrealistic as an option. I looked at > the cost of pulling in and selectively compiling (libs) an entire > boost 1.6, and that went a lot easier (added less than a minute to my build time). > > Matt > > ----- Original Message ----- > > From: "Sage Weil" <sweil@xxxxxxxxxx> > > To: "Allen Samuels" <Allen.Samuels@xxxxxxxxxxx> > > Cc: ceph-devel@xxxxxxxxxxxxxxx, mbenjami@xxxxxxxxxx, > > cbodley@xxxxxxxxxx > > Sent: Wednesday, February 3, 2016 3:04:57 PM > > Subject: Re: inline vector container > > > > On Wed, 3 Feb 2016, Allen Samuels wrote: > > > One thing that the code base needs is a simple vector container > > > that is optimized for a small number of elements, i.e., for small > > > element counts we avoid the malloc/free overhead. But fully > > > supports being resized into larger containers that are unbounded. > > > Of course it will need to follow all of the proper object > > > copy/move semantics so that things like unique_ptr, etc work > > > correctly. > > > > > > I heard rumors that there was one available in the boost world, > > > but I can’t seem to find it. Do you know about one being > > > available? > > > > http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_ > > vector.html > > > > > I’ve been prototyping one myself, just to get re-familiar with all > > > of the > > > C++11 move sementics, and trivial constructors, etc. > > > > > > The code is pretty complete, but the testing gets rather involved. > > > There’s > > > no reason to contain this if it’s available elsewhere. But if it > > > isn’t I plan on continuing this… > > > > I think Casey had prototyped something similar using a custom > > allocator, too, but I didn't actually look at the result. And Matt > > talked about just pulling the boost one in-tree until we get updated > > boost in the supported distros, but I forget if he ran into problems there or not... > > > > sage > > -- > -- > Matt Benjamin > Red Hat, Inc. > 315 West Huron Street, Suite 140A > Ann Arbor, Michigan 48103 > > http://www.redhat.com/en/technologies/storage > > tel. 734-707-0660 > fax. 734-769-8938 > cel. 734-216-5309 > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" > in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo > info at http://vger.kernel.org/majordomo-info.html > PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
