On Wed, 2009-01-28 at 20:52 +0300, Kirill Palagin wrote: > Hi Eike. > > Eike Rathke пишет: > > Hi Kirill, > > > > On Tuesday, 2009-01-27 22:13:50 +0300, Kirill Palagin wrote: > > > > > >> Please see http://www.openoffice.org/issues/show_bug.cgi?id=55266 - Calc > >> allocates 1.1GB of RAM for 81kb file with DataPilot.. > >> > > > > That may be fixed with > > http://qa.openoffice.org/issues/show_bug.cgi?id=93998 > > in CWS koheidatapilot02 integrated to DEV300_m37, please check. > > > m39 still tries to allocate >1GB of RAM.
Well, the fix in koheidatapiot02 deals with an entire different issue than i55266. So, I'm not at all surprised. Fixing i55266 (and probably i97886) needs a non-trivial refactoring since the reason for such large memory footprint may be a design issue. Current data pilot's result computation code uses a recursive algorithm, and each recursion instantiates a new set of objects. Unfortunately, when the number of unique field member values becomes large, which is certainly the case for the above referenced issues, the size of instantiated objects grows, and the memory usage spikes. Note that this algorithm is *not* weak against the total size of a source data, but is weak against the large number of unique field member values. We could first try to minimize memory use without changing the algorithm itself (by reusing some of the same tricks I used to reduce memory usage in the cache table). But if that turns out to be insufficient, then we may have to re-write the algorithm itself, in which case the required effort becomes pretty significant. Anyway, this is my initial thought on this issue. Looking deeper may reveal more detailed view of the problem. Kohei --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
