I don't think this is the only case to show all possible memory leaks. Here we'd better have a base line of leaked memory number with a set of files, a set of common use cases and a fixed loop count. By comparing with that base line we can see the progress in that area in the future.
zhangjf On Mon, Jun 11, 2012 at 9:17 AM, Zhe Liu <[email protected]> wrote: > Unfortunately，I lost Mac data and forget the iteration count. > Fortunately, I also did the same test on Ubuntu: > 361 iterations, 48hours, memory changed from 122644KB to 1133668KB， > +2800KB per iteration. > > 2012/6/9 Rob Weir <[email protected]>: >> On Thu, Jun 7, 2012 at 9:43 PM, Zhe Liu <[email protected]> wrote: >>> Hi all, >>> This week I did some long-running GUI testing on AOO 3.4 using Java on >>> my iMac. After about 23 hours, the memory occupied by soffice changed >>> from 90MB to 600MB. And soffice became very slow. >>> My scenario is >>> 1. Create new Text Document/Spreadsheet/Presentation/Drawing. >>> 2. Input some simple text in it. >>> 3. Save and then reopen it. >>> 4. Repeat the above steps. >> >> How many iterations of this loop did you do in 23 hours? >> >> It would be good to know the average leak per iteration, i.e., (600-90MB)/N >> == ? >> >> Although few end-users will use AOO like this, it is a good example of >> what someone might do if they ran OpenOffice on the server, to >> automate document conversions, etc. So it is important to reduce >> memory leaks. >> >>> I think AOO has memory leak issue. Did we perform this kind of testing >>> before? >> >> Not in 3.4. >> >>> -- >>> Best Regards >>> From [email protected] > > > > -- > Best Regards > From [email protected]
