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.