[Development] OK to add zero/bulk copy to QVector?
Konstantin Ritt
ritt.ks at gmail.com
Mon Dec 30 08:05:43 CET 2013
And again, " QVector::setBuffer()" sounds like if it were setting the
QVector buffer and the buffer routines, but any operation that is going to
modify the content would cause QVector to detach and copy the data -- thus
producing a new, writable QVector instance instead of manipulating the data
on a given buffer, which is pretty much expected.
Well, that's MHO...
Regards,
Konstantin
2013/12/30 Jiergir Ogoerg <f35f22fan at gmail.com>
> Well, I don't find setBuffer(buf, element_count) ambiguous, at the end
> of the day (1) one should read the docs first before using a method
> and (2) we can rename it to something that doesn't sound ambiguous.
> C++ (and Qt I believe) are about both efficiency and flexibility, the
> one I'm proposing (with whatever name is chosen to sound
> non-ambiguous) is a bit more efficient and more flexible. Or implement
> both (possibly sharing code underneath) and let the user decide which
> one to use.
>
> The other question is zero-copy which I'd like it to feature because
> it can be quite a win in some cases. I haven't looked at the source
> code for QVector so don't know if it can be done technically.
>
> On Mon, Dec 30, 2013 at 3:42 AM, Konstantin Ritt <ritt.ks at gmail.com>
> wrote:
> >> the 1st one is created automatically when the parent class
> > is created which holds the vector, and a second vector is created when
> > calling "fromRawData()" when I got the data on the heap to replace
> > the vector's buffer.
> >
> > From the one side, looking to the "QVector(const T *data, int size)" API,
> > one'd say QVector copies the data so that the original data could be
> freed
> > (because we do that everywhere else, look i.e. QString, QByteArray,
> > etc.)...surprise;
> > From the other side, creating a null QVector() (by using a default ctor)
> is
> > no-alloc operation and costs you near to nothing (note Qt containers use
> the
> > power of COW). "QVector<T> data = QVector<T>::fromRawData(dataPtr,
> > dataSize)" costs you near to nothing once again but has a pretty nice,
> > non-ambiguous "fromRawData" name.
> >
> > Regards,
> > Konstantin
> >
> >
> > 2013/12/30 Jiergir Ogoerg <f35f22fan at gmail.com>
> >>
> >> I would vouch for a non static method in addition or instead of
> >> "static ...fromRawData(..)", because a non-static method
> >> allows to set the buffer of a vector (needless to mention - with a
> >> zero copy) at any time, not just at vector creation, otherwise,
> >> as noted in my previous example, I'd end up having to create two
> >> vectors - the 1st one is created automatically when the parent class
> >> is created which holds the vector, and a second vector is created when
> >> calling "fromRawData()" when I got the data on the heap to replace
> >> the vector's buffer.
> >> It's not a big deal, but I find it slightly better because it avoids a
> >> vector creation as in my case, and you can replace the buffer at any
> >> time
> >> it suits you.
> >>
> >>
> >> On Mon, Dec 30, 2013 at 2:45 AM, Konstantin Ritt <ritt.ks at gmail.com>
> >> wrote:
> >> >
> >> > There is a plan to add "static QVector<T> QVector::fromRawData(const
> T
> >> > *data, int size)". Though, I'm not sure if we can do this until 6.0.
> >> >
> >> > Regards,
> >> > Konstantin
> >> >
> >> >
> >> > 2013/12/30 Jiergir Ogoerg <f35f22fan at gmail.com>
> >> >>
> >> >> QVector is created before I can load the array on the heap, so I
> can't
> >> >> init it to the desired
> >> >> item count.
> >> >> Particularly I'm talking about QVector<QComposeTableElement>
> >> >> m_composeTable
> >> >> from
> >> >>
> >> >>
> >> >>
> qt5/qtbase/src/plugins/platforminputcontexts/compose/generator/qtablegenerator.h
> >> >>
> >> >> And because of that I have to (can) resize() it, and resizing sucks
> >> >> because it not just creates
> >> >> more space for the internal buffer but also initializes each item to
> >> >> the default value.
> >> >>
> >> >> The other option to resize() is reserve, but it doesn't also increase
> >> >> the item count of the vector so
> >> >> I still have to go over each element and push_back().
> >> >>
> >> >> Just setting the whole thing with one qvector->setBuffer(array) would
> >> >> be quicker and faster.
> >> >>
> >> >> The example:
> >> >> The actual source code is attached (as zip file) in the file
> >> >> qtablegenerator.cpp, at static function loadCache(..),
> >> >> the quickest approach I could figure out was to use reserve() and
> then
> >> >> push_back() on each item,
> >> >> which still does lots of copies:
> >> >>
> >> >> QComposeTableElement *elem;
> >> >> vec->reserve(kElemCount);
> >> >>
> >> >> for(int i=0; i<kElemCount; i++) {
> >> >> elem = (QComposeTableElement*) (buf + (i * kElemSize));
> >> >> vec->push_back(*elem);
> >> >> }
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sun, Dec 29, 2013 at 11:44 PM, Yves Bailly <
> yves.bailly at laposte.net>
> >> >> wrote:
> >> >> > On 29/12/2013 20:10, Jiergir Ogoerg wrote:
> >> >> >> Hi,
> >> >> >> there are 2 simple options to speed up setting/adding elements to
> a
> >> >> >> vector when a heap buffer is filled in in advance:
> >> >> >> 1) Bulk copy.
> >> >> >> Assign a bunch of elements at once (from another vector or array),
> >> >> >> like std::vector::assign() does.
> >> >> >> A big extra copy happens, but avoids multiple calls to
> push_back().
> >> >> >
> >> >> > What about this, re-using your example:
> >> >> > my_struct *arr = new my_struct[count];
> >> >> > QVector<my_struct> v(count);
> >> >> > memcpy(v.data(), arr, sizeof(my_struct)*count);
> >> >> >
> >> >> > Assuming "my_struct" doesn't contain self-referencing references or
> >> >> > virtual table.
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > --
> >> >> > (o< | Yves Bailly | -o)
> >> >> > //\ | Linux Dijon : http://www.coagul.org | //\
> >> >> > \_/ | | \_/`
> >> >> > _______________________________________________
> >> >> > Development mailing list
> >> >> > Development at qt-project.org
> >> >> > http://lists.qt-project.org/mailman/listinfo/development
> >> >>
> >> >> _______________________________________________
> >> >> Development mailing list
> >> >> Development at qt-project.org
> >> >> http://lists.qt-project.org/mailman/listinfo/development
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > Development mailing list
> >> > Development at qt-project.org
> >> > http://lists.qt-project.org/mailman/listinfo/development
> >> >
> >> _______________________________________________
> >> Development mailing list
> >> Development at qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> >
> >
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131230/35f05b2b/attachment.html>
More information about the Development
mailing list