Please attach an example document, so we can benchmark.
What were your parameters for OOo 3.2.1?

With LibreOffice, I tried with
./soffice --convert-to pdf filename --headless

Those don't work in OOo.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document and more information.

Starting in the Openoffice 3.2.1. 
./soffice -headless -accept="socket,host=localhost,port=8100;urp;" -nocrashreport -nodefault -nofirststartwizard -nolockcheck -nologo -norestore

Starting in the Libreoffice 4.3.3.  
./soffice --headless --accept="socket,host=localhost,port=8101;urp;" --nocrashreport --nodefault --nofirststartwizard --nolockcheck --nologo --norestore

Tests were conducted on documents with different sizes with pictures.

Sample document in attachment. 

I will add that headless mode for use as a background application, that is running on an application server through port.

Please confirmed

Created attachment 116986 [details]
Sample document for export to pdf

LibreOffice 4.4.4 took 2 seconds to convert it.

OpenOffice 3.3 freezes in the command line, when I try:
-headless -accept="socket,host=localhost,port=8100;urp;" -nocrashreport -nodefault -nofirststartwizard -nolockcheck -nologo -norestore -convert-to pdf vzor.odt

How do you do the pdf conversion exactly? You didn't include the parameters. Do you use the exact same parameters as in my above line?

(In reply to Tomas Kralik from comment #0)
> An interesting situation is when compared LO 4.4.2.2. on different systems.
> Installing LO on server with redhat 6.6 in headless mode is about 2 times
> slower against instalation server with Mint 17.01.

Do you really mean "installing" or are you still talking about converting with your sentence?

Btw. could the slowness be about network name resolution? Timing out when querying localhost? Can you debug it?

Could it be the same issue as this: http://lists.freedesktop.org/archives/libreoffice/2015-January/065570.html

First post: http://lists.freedesktop.org/archives/libreoffice/2014-December/065499.html

This fix was added to work around systems that are broken in that manner: https://gerrit.libreoffice.org/#/c/13856/

Fix should be in 4.4.0 already, so I'm not sure..

Ok, the fix is not in 4.4 branch. You should try with 5.0 RC2 and see, if the problem persists. You should also look into your server setup.

first excuse I was away from civilization, so I did not react :-)

Yes, I've used these switches to install OO on Red Hat EL 6.6 and Mint 17.1KDE and normally I passed the test.



(In reply to Beluga from comment #5)
> LibreOffice 4.4.4 took 2 seconds to convert it.
> 
> OpenOffice 3.3 freezes in the command line, when I try:
> -headless -accept="socket,host=localhost,port=8100;urp;" -nocrashreport
> -nodefault -nofirststartwizard -nolockcheck -nologo -norestore -convert-to
> pdf vzor.odt
> 
> How do you do the pdf conversion exactly? You didn't include the parameters.
> Do you use the exact same parameters as in my above line?

(In reply to Beluga from comment #6)
> (In reply to Tomas Kralik from comment #0)
> > An interesting situation is when compared LO 4.4.2.2. on different systems.
> > Installing LO on server with redhat 6.6 in headless mode is about 2 times
> > slower against instalation server with Mint 17.01.
> 
> Do you really mean "installing" or are you still talking about converting
> with your sentence?

Here I am referring to the rate of conversion into pdf. Within two Linux distributions.

> Btw. could the slowness be about network name resolution? Timing out when
> querying localhost? Can you debug it?

A network problem that can not be tested on multiple devices, whether locally or on a remote server. I'm talking about the installation location.


> Could it be the same issue as this:
> http://lists.freedesktop.org/archives/libreoffice/2015-January/065570.html
> 
> First post:
> http://lists.freedesktop.org/archives/libreoffice/2014-December/065499.html
> 
> This fix was added to work around systems that are broken in that manner:
> https://gerrit.libreoffice.org/#/c/13856/
> 
> Fix should be in 4.4.0 already, so I'm not sure..

Please test with 5.0 RC3 and see, if the PDF generation speed issue is solved. Please also look into fixing your server setup to remedy the real issue.

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED FIXED, if the problem went away.

Unfortunately 5.0.0.3 LibreOffice is not faster than in version 4.4.2. Even as a little slower. However, let us return to the problem of speed generate pdf. Thus, comparing speeds between LO 4.4.2 and 3.2.1 OO. In Annex I add an attachment. Simple odt. There is a difference between the speed as follows: 
LO is 10 times slower than OO.
The average generation time attached document is 90 ms at OO.
The average generation time attached document is 810 ms to LO.
User configuration I have the same in both versions.
Both versions are running headless mode with the same switches. On the same machine.

Created attachment 118069 [details]
SimpleDocument

Clearly not a major bug. Please don't over prioritize your bugs.

Major is retained for crashers, loss of data, and the like...


Minor - slows down professional quality work (from what I can read in the comments...it's by milliseconds?? might not even deserve minor);
Low - default.

If OO document generated in 90 ms and LO is now generates over 810 ms consider it a huge problem. For example, if you generate daily 80,000 documents so the difference is unreal ...

(In reply to Tomas Kralik from comment #14)
> If OO document generated in 90 ms and LO is now generates over 810 ms
> consider it a huge problem. For example, if you generate daily 80,000
> documents so the difference is unreal ...

I don't see that you mention anything about the resulting PDF. Are the sizes comparable, are the images present in LO generated PDF converted to bitmap rather than vector? Suspect the issue is in that facet.

...everyone thinks their bugs are "huge problems" but we use an objective standard that takes these personal biases out of the picture. Minor is appropriate. If you're using this in a business setting (which I suspect you might be doing if you have that number of documents) I suggest you get L3 support and then a certified developer can and will focus on the issue (i.e., you can dictate what is fixed and when)

https://www.documentfoundation.org/certification/developers/

@ Tomas Kralik 
is the bug still present in LibO 5.2.4.2?

status NEEDINFO
revert it to UNCONFIRMED if bug is still present or change it to RESOLVED WORKSFORME if bug is gone

NEEDINFO until then