Thanks for the explanation Paul. It makes sense that we want to preallocate for performance. It looks like the setSafe bug you mentioned was fixed, since there is an explicit check for it. But I've run into a couple more issues with adding to an empty VariableLength Vector and an empty RepeatedVector. I started going down the road of making that behavior work, but since that behavior isn't useful maybe I'll just document that you have to call allocateNew on a vector before using it and add an assert statement to enforce that requirement on all the vectors.
Thanks, Tim On Wed, Aug 15, 2018 at 6:21 PM, Paul Rogers <[email protected]> wrote: > Hi Tim, > > IIRC, you have to do an initial allocation. There was a bug that, if you > didn't, the setSafe would try to double your vector from 0 items to 0 > items. This would be t0o small, so it would double again, forever. > > In general, you don't want to start with an empty vector (or the default > size you get on a plain alloc()). Your code will waste time doubling your > vector up to the desired size. > > Instead, use the available information ("sizer" and accompanying > allocation tool in an internal operator, or your best guess in a reader) to > allocate the vector to the desired final size. (The result set loader > handles this busy work for you, BTW.) > > > If you turn on detailed logging in vectors, you'll see, and be alarmed by, > the number of doublings that happen otherwise. > > > Thanks, > - Paul > > > > On Wednesday, August 15, 2018, 6:11:49 PM PDT, Timothy Farkas < > [email protected]> wrote: > > I'm currently observing a bug and I believe the source of it may be a > misunderstanding I have about the usage of value vectors. If I create any > value vector using it's constructor, is it safe to use the addSafe / > setSafe methods on it out of the box? Or do I have to call allocateNew or > allocateNewSafe on it before I do anything in order to safely start > manipulating it? > > Thanks, > Tim > >
