Re: inline vector container

[Matt Benjamin <mbenjamin@redhat.com>]

Yeah, that looks a lot more reasonable if we must split it out, though I would prefer boost.

Matt

----- Original Message -----
> From: "Milosz Tanski" <milosz@adfin.com>
> To: "Matt Benjamin" <mbenjamin@redhat.com>
> Cc: "Sage Weil" <sweil@redhat.com>, "Allen Samuels" <Allen.Samuels@sandisk.com>, "ceph-devel"
> <ceph-devel@vger.kernel.org>, cbodley@redhat.com
> Sent: Wednesday, February 3, 2016 4:21:12 PM
> Subject: Re: inline vector container
> 
> On Wed, Feb 3, 2016 at 3:57 PM, Matt Benjamin <mbenjamin@redhat.com> wrote:
> >
> > 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@redhat.com>
> > > To: "Allen Samuels" <Allen.Samuels@sandisk.com>
> > > Cc: ceph-devel@vger.kernel.org, mbenjami@redhat.com, cbodley@redhat.com
> > > 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
> 
> 
> The fb / folly code also has a small vector:
> https://github.com/facebook/folly/blob/master/folly/small_vector.h
> that used a C++11 move semantics whenever possible. Compared other
> parts of folly this has pretty small dependencies on folly and those
> can prob be ripped out.
> 
> >
> >
> > >
> > > > 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@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> 
> --
> Milosz Tanski
> CTO
> 16 East 34th Street, 15th floor
> New York, NY 10016
> 
> p: 646-253-9055
> e: milosz@adfin.com
> 

-- 
-- 
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html