Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Printing through c++ bridge takes much longer then through COM/Basic | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | gsl | Reporter: | martho <martin> | ||||||
Component: | code | Assignee: | martho <martin> | ||||||
Status: | CLOSED FIXED | QA Contact: | issues@api <issues> | ||||||
Severity: | Trivial | ||||||||
Priority: | P2 | CC: | daniel, issues | ||||||
Version: | OOo 1.1 RC3 | ||||||||
Target Milestone: | OOo 1.1.1 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows 2000 | ||||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
Developer Difficulty: | --- | ||||||||
Attachments: |
|
Description
martho
2003-09-01 10:37:56 UTC
Created attachment 8917 [details]
VC++-Project which prints through COM and through the Bridge
Created attachment 8918 [details]
3-Page-Test-Document (Text, 2 Pics)
implementation issue AS->Daniel: Sorry - but I think you dont measure the time for printing here. Your test measure the time, which is needed to call the remote interface and return back from there. The implementation behind this interface is everytimes the same, the printed document isnt changed => so the time needed for printing (which is done inside the remote office proccess and not inside your client application) must be the same. No data of the printing document are transfered due to the bridge! And as you already know from #i14397#: calling of XPrintable.print() without any special parameter starts the print job as an asynchronous process ... and the interface call returns immediatly after printing was started. I suggest, that marshalling due to the C++ bridge is slower then due to the COM bridge. And further ... NO this bug isnt related to #i14397#! Because there you describe the problem with an asynchronous print job in relation to closing the document, which is a multithreading issue. AS->DBO: I guess - its your ... Hi Andreas, thanx for your reply. You are right that I'm measuring the time between the call and the return of the call. But I have 2 arguments that it's not the call which makes the different: 1.) In general "early binding" (C++-Call) is faster then a "late binding" (COM-call). I've tested several other funtions where this is always true. So I think, a delay of 37 sec can't be explained as only "time for mashalling". 2.) The blue progress bar really is slower when the call is invoked from C++ then from COM. Because this could be only meassured subjectivly, I showed a view other people the progress bar - all of them said that the bar progresses much slower when the C++-call is used. I, too, have to explanaition for this. @ssa: as commincated by kso to you... reassigned. KSO->SSA: Just investiagted a little into the problem. First, yes, it's reproducable. The big difference is that when using COM the print() UNO method gets always called from within the main thread of the Office process and when using the URP (C++) bridge the method always gets called from another thread (not-main). Looking at vcl/win/source/app/slainst.cxx -> SalInstance::Yield() I found a Sleep(1) in case we're not in the main thread. I removed this (only for testing) and ... printing time did not differ anymore! The sleep during yield which is called from a thread different to the main thread was required to get rid of a dead lock that was triggered by trying to switch to the busy main thread by sending a message. I'll try to detect this situation and sleep only when the the main thread is busy, this should cure the performance problem. Changed target milestone. The (time-consuming) sleep call is now only used when the deadlock scenario is given, ie, when there is already a yielding dialog that might block the main thread. Thanx for the fast fixing! ssa->kso: please verify. Looks good. ... and VERIFIED. Martin, you should close this issue after verifiying that the fix works for you in OOo 1.1.1 -> Ack Setting from KSO are not taken. Set to Verified. close issue. |