Re: Build light weight conversion binary

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.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot