[odb-users] Nested vector

[Zeyang Tao]

Hi Boris,

Thanks for your reply.

I am using postgresql.

Yes, I used odb::vector and only updated the elements which have been
changed. It improved the performance a lot but we can still see the
slowness issue accidentally.

If I have pre knowledge about the matrix size, I think I can get rid of X
and Y, do you think that will make a big difference ?

Thanks

2015-11-23 7:32 GMT-06:00 Boris Kolpackov <boris at codesynthesis.com>:

> Hi,
>
> Zeyang Tao <zeyangtao1020 at gmail.com> writes:
>
> > Recently we had a slowness issue in ODB, the thing is ODB doesn't support
> > nested vector, i.e vector of vector, so in order to store that kind of
> data
> > structure, we have to use the following hacky way,
> >
> > struct node{
> > int x, y;
> > double value;
> > }
> >
> > class parameter{
> > ...
> > ...
> > vector<node> cnt;
> > }
>
> One thing you can improve on here is to use the vector's index for 'x',
> e.g.,
>
> struct node
> {
>   size_t y;
>   double value;
> };
>
> vector<node> cnt;
>
> Or, if you want to keep x and y, you can mark the cnt member as
> unordered (Section 14.4.19).
>
>
> > basically the cnt is a matrix and we use x and y as the index, each
> single
> > node will be a record in the sub table, sometimes the matrix is large and
> > one update will write N^2 records to the subtable, plus this update is
> very
> > frequent, so we saw 2-3 seconds delay constantly
>
> I think the first thing you should try is the change-tracking vector
> (Section 5.4). Unless you always modify most of your elements, I bet
> it will solve your problem.
>
> Also, there could be some database system-specific ways to optimize
> this (e.g., some databases support arrays of simple types). But since
> you didn't mention which database you are using (always are good idea),
> I can't recommend anything specific in this area.
>
> Boris
>