Hi Jerry,
On Thu, 2012-07-19 at 22:26 -0700, Jerry Tan wrote:
> The company that I work for use LibreOffice as the main word
> processor. We convert a lot of client letters from doc/docx to open
> document format.
Sounds like a good use-case :-)
> We are on Mac OS X Lion (10.7) btw. We use: soffice --headless
> --convert-to odt …. to do the batch conversion.
Seems sensible.
> The problems with this are:
> - It takes quite a long time to start up. It becomes a problem when we
> have to convert many documents.
This is a matter of profiling; when you say "quite a long time" - how
long are you talking ? :-) Also, is your concern cold or warm startup
time ?
> - It won't work if there is already a LibreOffice instance running
That should be easy enough to fix; it's a matter of not checking the
OSL_PIPE that we setup to send arguments to the main process. It is
possible that --nolockcheck does that, or perhaps there is a hidden
argument for that.
> So my boss asked me to fix these 2 issues. I managed to build the
> source code on Mac OS X Lion and then try to see what's going on
> (unfortunately specifying --headless fail to build).
So - --headless doesn't work well for Mac, there is a need for some
work there to fix it. There are really two different approaches - one is
to re-factor the font code so it is re-usable without setting up the
display / head logic, the other is to build & use freetype on mac, and
re-use the Linux code for font rendering etc.
There are also some nice sillies going on; last I looked there was some
considerable proportion of the time rendering a nice gradient background
to a bitmap view of the window you can't see when using --headless ;-) I
suspect just profiling and turning off a lot of that fluff would
accelerate things for you. But -always- profile before optimisting.
Callgrind-for-mac + KCachegrind on Linux would be a great pair of free
tools if you have nothing better.
> I found out that to just do the conversion, there are many dynamic
> libraries are loaded (so I guess this is why it takes a long time).
That's not obvious to me, and I've done lots of work on profiling. If
you want faster cold-start, you can try using the --enable-mergelib
build mode - that builds a ton of the code into a single, huge library -
it may help you: I'd be interested in some hard profiling results from
that.
> Trying to understand what's going on in the code is not a simple task
> to be honest. Can some one help or give me info on how to:
:-)
> - build a bare minimum/small binary (without too many dependencies)
> just for conversion to odt? also how do I link statically?
> The conversion utility doesn't need all the gui libraries I believe.
> Minimum dependency will make start up a lot quicker.
So - those fragmented libraries help you there - the UI pieces
shouldn't be linked on startup.
> - what to do to allow conversion working while there is an instance of
> LibreOffice already running? Should I modify something in the source
> code?
That should be easyish cf. above. See
desktop/source/app/officeipcthread.cxx and thereabouts :-)
> I'm sure a lot of people would love to have this light weight
> conversion utility.
Thanks so much for jumping in !
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
