|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Reuse the original stream of OLE object from the MS document on loading. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Writer | Reporter: | pmike <www.openoffice.org> | ||||
| Component: | code | Assignee: | AOO issues mailing list <issues> | ||||
| Status: | REOPENED --- | QA Contact: | |||||
| Severity: | Trivial | ||||||
| Priority: | P3 | CC: | issues, kozodaevroman, Mathias_Bauer | ||||
| Version: | OOo 2.0.4 | Keywords: | performance | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
| Developer Difficulty: | --- | ||||||
| Attachments: |
|
||||||
|
Description
pmike
2006-10-18 07:59:06 UTC
Created attachment 39846 [details] sample file, compressed with 7-zip, http://7-zip.org/ pmike->mru: I use 7-zip archiver to make file smaller than 1Mb. If this format is not acceptable I can send file by mail. MRU->MAV: indeed the attached document needs VERY long time to be opened. this should be treated as a defect and solved in a later version of OOo. OOo 2.3 still uses TMP files a lot. Should someone set target milestone for this issue? When I making techinal documentation I use many formulas, and then this trouble ricing to hard very rapidly. And when I use AntiVirus program - using of OLE-object make very logner... :`( This is framework issue. I have sample presentation (~7Mb, cannot be attached here). It opens by Impress in 20 minutes (2GHz Athlon X2, 1Gb RAM), and creates over 17000 temporary files too. I almost sure Calc doc with many OLE objects will opens the same way. The extremely slow performance on loading of a document with many embedded objects in OOo2.3 seems to be the duplicate to issue 81789, that is fixed in OOo2.3.1. As for the big amount of temporary files in this case, this problem is addressed by issue 60124. So I close this issue as a duplicate to issue 81789. *** This issue has been marked as a duplicate of 81789 *** Ok, in this case the issue 81789 would affect the document only slightly. The problem is that the embedded objects are imported from the word document and the streams are integrated into the temporary storage. This problem was already discussed and a good solution would be reusing of the stream from the original word document. So this is a good issue that could be used to address the problem. Reopening and setting the target to 3.x for now. Hello everyone! Any news about this issue? Performance penalty with temp files is huge, and there is no workaround. As target points the issue is planned to be solved in one of the future releases of 3.x branch. Currently there are no resources to get it in 3.1. By the way, the workaround is to use OOo format. Well, after fix of issue 101219 load time is better but still long. Just tested with OOo-dev m50 on Linux. It seems that solution in 101219 is not perfect: temp files ARE created, but then erased almost immediately. Only 4 of them left after the file opens completely. Close document perf. is great - it's no longer need to erase thousands of temps! Maybe some streams have been opened with the requirement to be seekable? In this case we have to create a temp file. Quite often this happens when SvStreams are used as they are always seekable. mav->pmike: I must confess I do not quite understand the idea of your comment. The sentences like "better but still long" and "is not perfect" can not be treated as a constructive critic. Actually they could be used for any performance improvement. The only concrete sentence there is that the temporary files are still created, but it is intended so, please read the description of the issue 101219 one more time. The memory is used only for small streams, so the temporary files are still created for big streams. It is a compromise between performance and memory usage. mav->mba: The streams are inserted to the storage during the import from MS format currently ( this bug is actually about avoiding such insertion ), as result a temporary medium is necessary. So for the big streams the temporary files are still used. After this bug is fixed no temporary medium ( either memory or file ) should be used for the object stream until it is changed. The stream should be read from the imported document if possible. Here we have another problem, the whole document has to be copied in this case, to be sure that in case of network outage and etc. the document contents are still available. We will have to find a good compromise here. pmike->mav: Well, here is approximate times: OOo 3.0.1 9ubuntu3: open - 190 secs, 17366 temp files, close - 5 secs OOo-dev-3.2 m50 : open - 120 secs (~40% faster), 8 temp files, close - 2 secs PS. reading your answer to mba eliminates all my other questions :) mav->pmike: Thank you for the statistic. I think I see now what you meant, indeed there is still enough place for improvement, and fix for this issue might be a valuable change for the scenario. Reset assigne to the default "issues@openoffice.apache.org". |