Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index



On Mon, 2012-05-21 at 12:03 +0200, Stephan Bergmann wrote:
On 05/21/2012 10:28 AM, Michael Meeks wrote:
    I assume this is from C++ (?) anything else would of course cause tons
of bridging overhead in the streams.

 From the code, it looks more like they are using Java, presumably from 
a remote process.  So any data from the buffer needs to be marshalled 
through (remote) UNO to OOo/LO's C++ side.  What can potentially reduce 
throughput there is if the C++ side calls XInputStream.readBytes in 
small instead of large chunks, but I don't know the implementation 
details of the relevant Calc import code.

        Ah - in which case, thousands of calls via the Java bridge will be
where the time is spent I suppose :-); I suggest writing the data out to
a file, and/or (somehow?) creating an UNO memory-stream and writing the
data to it all in one big lump, so the code can do native C++ <-> C++
for reading that back out. For the quick & easy fix the temporary file
is almost certainly far faster - I assume you're keeping it in memory to
try to make it fast ? :-)

        HTH,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.