[PUSHED:3-6] [URGENT] horrible performance regression

I trust you you know what you are doing in Base :) Looks ok.

I cherry-picked it

Fridrich

On 17/07/12 00:10, Lionel Elie Mamane wrote:
> Please cherry-pick 0cda6605844ef68e45db7a7c05cc4d09ef2bc49a
> (http://cgit.freedesktop.org/libreoffice/core/commit/?id=0cda6605844ef68e45db7a7c05cc4d09ef2bc49a
>  and patch also attached)
> to libreoffice-3-6 in time for rc2. This would allow me to get some
> Base testers in 3.6 before release (as it is, embedded HSQLDB is so
> slow as to be unusable).
>
> I'll make a backport to libreoffice-3-5 later this week or next
> week, now I have to run to catch a train (that patch most probably
> won't apply to libreoffice-3-5.) There are other performance problems
> to clean up (fdo#52170, fdo#51976), but I think they are far more
> minor that this one.
>
>
> Some explanation on the commit message: The structure is that a
> RowSetCache typically wraps a KeySet. RowSetCache caches a window of
> something like 20 or 100 rows, the underlying KeySet caches only the
> current row. But RowSetCache keeps its notion of current row and the
> wrapped KeySet's notion of current row synchronised, so it is
> important that when RowSetCache moves the KeySet's current row, but
> already has the data in its own cache, the KeySet does not refetch the
> row.
>
>
> fdo#51239 refresh row lazily (when data is requested)
>
> This avoids fetching data that will not be requested when the "cursor"
> is only moved and no data requested. That is typically what
> RowSetCache does when its own cursor is moved within its window.
>
> This basically makes the whole {next,previous,absolute,...}_checked
> story obsolete, by basically always being as fast as the
> i_bFetchRow==false case, but in a safer way.
>
> Change-Id: I89eaf277069736b3077bde8b45325929db290f2d
>
>
> Thanks folks!
>
>
>
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice