[PATCH] [REVIEW:3-6] [URGENT] horrible performance regression

Lionel Elie Mamane lionel at mamane.lu
Mon Jul 16 15:10:05 PDT 2012

Please cherry-pick 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

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!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fdo-51239-refresh-row-lazily-when-data-is-requested.patch
Type: text/x-diff
Size: 13936 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120717/a37a650d/attachment-0001.patch>

More information about the LibreOffice mailing list