On 2015-01-10 10:18 PM, Michael Meeks wrote:
On Sat, 2015-01-10 at 16:08 +0200, Noel Grandin wrote:
we should probably turn this on automatically for localhost connections.
Sounds eminently sensible - a patch ? =)
https://gerrit.libreoffice.org/#/c/13856/
On Sat, 2015-01-10 at 16:08 +0200, Noel Grandin wrote:
> we should probably turn this on automatically for localhost connections.
Sounds eminently sensible - a patch ? =)
ATB,
Michael.
--
michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot
Hrm.
I thought I tried that, but I see my mistake now: I didnt set
'tcpNoDelay=1" on *both* ends. Looks like Noel Grandin was right after all.
Oh, well.. At least I learned some more details on how to read and
interpret strace output in the process.
;)
- Maarten
On Sat, Jan 10, 2015 at 3:
we should probably turn this on automatically for localhost connections.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Thank you everybody for poking this problem. After much discussion in
different places I was able to resolve this: set the TCP_NODELAY flag
when setting up the connection on both sides. By passing the following
string:
uno:socket,host=localhost,port=2002,tcpNoDelay=1
when creating both the Of
Yes, that slowdown occurs with different versions of LO for me as well.
Jens
On Wed, Jan 07, 2015 at 03:50:21PM +0100, Maarten Hoes wrote:
>Hi,
>> wrote:
>>
>> Ah. I fear that this is a regression introduced through my code. This
>> sounds a bit like the glxtest codewhich mig
Hi,
On Wed, Jan 7, 2015 at 10:27 AM, Michael Meeks
wrote:
>
> Anyhow - hopefully that gives some pointers that you can puzzle
through
> & try to trace / chase down what's going wrong for you.
>
Thanks for that very elaborate investigation, and for taking the time to
explain the research.
Hi,
On Wed, Jan 7, 2015 at 3:17 PM, Markus Mohrhard <
markus.mohrh...@googlemail.com> wrote:
>
> Ah. I fear that this is a regression introduced through my code. This
sounds a bit like the glxtest codewhich might not work optimally in a
headless setup. I suppose you are using 4-4 or master.
>
> Re
Hey,
On Wed, Jan 7, 2015 at 10:27 AM, Michael Meeks
wrote:
> Hi Maarten,
>
> On Wed, 2015-01-07 at 09:21 +0100, Maarten Hoes wrote:
> > Two more things I noticed, though again Im not sure how relevant those
> > are, it's probably nothing :
>
> So the thing you're looking for looks often
Hi Maarten,
On Wed, 2015-01-07 at 09:21 +0100, Maarten Hoes wrote:
> Two more things I noticed, though again Im not sure how relevant those
> are, it's probably nothing :
So the thing you're looking for looks often like this:
3986 1420550762.879658 poll([{fd=6, events=POLLIN}], 1, 42949
Hrm.
Two more things I noticed, though again Im not sure how relevant those are,
it's probably nothing :
In one thread/pid (3986), I see about 300 occurances of '<... poll resumed>
) = 0 (Timeout)', and in the entire output (again thread/pid 3986, among
others) there are about 1100 lines of 'EAGA
Just a guess, but I would suspect that setting the TCP_NODELAY socket option on both ends of the socket would speed
things up considerably.
I think that some BSD-based operating systems have a loopback shortcut in their networking code, which would explain
some of the speed difference between
On Tue, 2015-01-06 at 15:20 +0100, Maarten Hoes wrote:
> Well I tried this, and it produced a file of a whopping 383087 lines
> and 30 MB.
That is expected.
> I wouldnt expect any sane person to look through all of that in its
> entirety on a page by page basis.
> ;)
Hit page-
Hi,
On Tue, Jan 6, 2015 at 1:28 PM, Michael Meeks
wrote:
>
> As Tor suggested doing an strace on each end would show what's up:
>
> strace -f -ttt -s 256 -o /tmp/slog slow_proces
>
> And poke in the /tmp/slog for where there is a multi-second jump
in the
> time - and past
On Tue, 2015-01-06 at 12:31 +0100, Maarten Hoes wrote:
> Im not sure. When I change the accept to include 'tcpNoDelay=1' as
> below:
In the past - the Linux desktop as a whole suffered something rather
similar when code tried to do a reverse lookup on the hostname which
took significant t
Hi,
Im not sure. When I change the accept to include 'tcpNoDelay=1' as below:
p =
subprocess.Popen("/home/buildslave/source/libo-core/instdir/program/soffice
--accept=\"socket,host=localhost,port=2002,tcpNoDelay=1;urp;StarOffice.ServiceManager\"
--headless", shell=True, env=myenv)
I get no noti
Hi,
On Mon, Jan 5, 2015 at 10:47 PM, Michael Stahl wrote:
>
> On 05.01.2015 18:36, Maarten Hoes wrote:
> >
> > For what its worth, i can easily reproduce the script takes fairly long
> > (about ~50 seconds on my vm's) to complete on both Ubuntu 14.04 and
> > Fedora 21, both with the distro suppl
On 05.01.2015 18:36, Maarten Hoes wrote:
>
> For what its worth, i can easily reproduce the script takes fairly long
> (about ~50 seconds on my vm's) to complete on both Ubuntu 14.04 and
> Fedora 21, both with the distro supplied binaries and a recent master.
>
> I ran the script using strace -f.
Thank you, Maarten.
I tried to upload the callgrind data, but the email was rejected due to
its size. Glad you can reproduce the slowness!
Now the question is: what's to cause of the socket slowness, compared to
the pipe performance? Based on yesterday's findings, this might not be
a LO issue a
The following is interesting:
On Sat, Jan 03, 2015 at 05:22:42PM +0100, Jens Tröger wrote:
>
> 32b LibreOffice on Mac (py 3.3.5)
> Elapsed time: 1.8361830711364746 with 550 pars
>
> 64b LibreOffice on Mac (py 3.3.5)
> Elapsed time: 0.8173670768737793 with 550 pars
>
> 64b LibreOffice
Oh, misunderstanding :) The attached files are already digested with
callgrind_annotate, you can just open in vim.
Jens
On Sat, Jan 03, 2015 at 08:08:23PM +0100, Maarten Hoes wrote:
>Hi,
>Perhaps its just me, but when I try to open up the traces you send, I
>get the following error
Hi,
Perhaps its just me, but when I try to open up the traces you send, I get
the following error message :
"Could not open the file 'callgrind.out.3708-annotate' Check that it exists
and you have enough permissions to read it."
I verified I have the proper permissions, so that is not the answe
On Sat, Jan 3, 2015 at 5:22 PM, Jens Tröger
wrote:
>
> I wonder if the poor perf got to do with UNO and Python. On my Mac, LO
ships
> with its own Python interpreter instead of just providing the UNO hooks
> like it does on Linux.
>
> 32b LibreOffice on Mac (py 3.3.5)
> Elapsed time: 1.836183
I wonder if the poor perf got to do with UNO and Python. On my Mac, LO ships
with its own Python interpreter instead of just providing the UNO hooks
like it does on Linux.
32b LibreOffice on Mac (py 3.3.5)
Elapsed time: 1.8361830711364746 with 550 pars
64b LibreOffice on Mac (py 3.3.5)
E
Hi,
On Sat, Jan 03, 2015 at 12:51:02PM +0100, Maarten Hoes wrote:
> wrote:
>>
>> Nearly all distros provide debuginfos that will make the callgrind
>> output somewhat nicer. In a self build tree you need to use
>> --enable-symbols as option (no enable-debug or enable-dbgutil as
Hi,
On Sat, Jan 3, 2015 at 12:28 PM, Markus Mohrhard <
markus.mohrh...@googlemail.com> wrote:
>
> Nearly all distros provide debuginfos that will make the callgrind output
somewhat nicer. In a self build tree you need to use --enable-symbols as
option (no enable-debug or enable-dbgutil as they wil
Hey,
On Sat, Jan 3, 2015 at 12:09 PM, Maarten Hoes
wrote:
>
>
> On Sat, Jan 3, 2015 at 12:37 AM, Jens Tröger
> wrote:
> >
> > Thank you, Maarten,
> >
> > I've run office like so from within the Python script:
> >
> > p = subprocess.Popen("valgrind --tool=callgrind soffice
> --accept=\"socket,
On Sat, Jan 3, 2015 at 12:37 AM, Jens Tröger
wrote:
>
> Thank you, Maarten,
>
> I've run office like so from within the Python script:
>
> p = subprocess.Popen("valgrind --tool=callgrind soffice
--accept=\"socket,host=localhost,port=2002;urp;StarOffice.ServiceManager\"",
shell=True, env=myenv)
>
Thank you, Maarten,
I've run office like so from within the Python script:
p = subprocess.Popen("valgrind --tool=callgrind soffice
--accept=\"socket,host=localhost,port=2002;urp;StarOffice.ServiceManager\"",
shell=True, env=myenv)
and got five callgrind.out.* files once the script terminated
On Tue, Dec 30, 2014 at 4:44 PM, Maarten Hoes
wrote:
>
> On Tue, Dec 30, 2014 at 4:24 PM, Jens Tröger
wrote:
> >
> > hopefully function call profiling yields more...
> >
> Which makes the following question pop up in my mind: does the wiki
already have a page describing how to set up function cal
The Mac builds (which run the test document in 1s) come directly from
the website, whatever .dmg is being distributed.
Both Linux builds, Gentoo and Ubuntu, come through their respective
packaging system.
Are you saying that with each step of the UNO paragraph iteration,
office calls home?
On W
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/12/14 12:50, Jens Tröger wrote:
> Unless office attempts to connect "somewhere" (where to, anyway?)
Where are you getting the builds from?
On at least one distro, the version in their repository calls home.
jonathon
-BEGIN PGP SIGNATURE
I have no preference tools-wise.
On Tue, Dec 30, 2014 at 04:44:42PM +0100, Maarten Hoes wrote:
>Which makes the following question pop up in my mind: does the wiki
>already have a page describing how to set up function call profiling
>with libreoffice ? (i couldnt find any). Is there
On Tue, Dec 30, 2014 at 4:24 PM, Jens Tröger
wrote:
>
> hopefully function call profiling yields more...
>
Which makes the following question pop up in my mind: does the wiki already
have a page describing how to set up function call profiling with
libreoffice ? (i couldnt find any). Is there a st
Thanks Maarten,
I'll take a look at the links, and I'll check if Ubuntu provides dbg
information. Strace didn't log anything calls other than wait for the
loop iteration; hopefully function call profiling yields more...
Jens
On Tue, Dec 30, 2014 at 04:06:04PM +0100, Maarten Hoes wrote:
>Hi
Hi,
On Tue, Dec 30, 2014 at 2:14 PM, Jens Tröger
wrote:
>
> Are there prebuild drops that contain dbg and prof information already
> which I can work with?
>
Im not sure if the daily builds you can find here have debug symbols
included (for example, 'Linux-rpm_deb-x86_64@46-TDF-dbg' sounds pro
I'd love to, however, I can't even build the thing. See my other thread
on autogen.sh failing. Also, I figure that somebody who works on LO
might know what's going on, and I hoped that I don't have to spend days
trying to dig around something that might be obvious to the devs.
Are there prebuild
> You or we can now speculate for a long time or you can just start
> profiling what is actually slow. Get a symbols build and run it with
> callgrind.
>
Or even just run it under strace for a start, doesn't even require
re-building it.
--tml
___
LibreO
Hey,
On Tue, Dec 30, 2014 at 1:50 PM, Jens Tröger
wrote:
> Connection is not the problem, I have already connected and that took
> far less than a second on localhost. The code in question is this:
>
> start_time = time.time()
>
> parenum = document.Text.createEnumeration()
> while
Connection is not the problem, I have already connected and that took
far less than a second on localhost. The code in question is this:
start_time = time.time()
when connecting to something on the local machine, if the machine name
or the localhosts entry is /etc/hosts
is incorrectly setup, the connection process can take an extra 30
seconds while the socket library performs a DNS lookup that times out.
___
Libre
That would mean that with every access through the UNO bridge and
advance of the paragraph iterator, office would make some network
access? Why?
On Mon, Dec 29, 2014 at 01:44:51PM +0200, Noel Grandin wrote:
> That smells like a DNS timeout. I suspect that you have some kind of
> network problem.
Hello,
Il 29/12/2014 12:02, Jens Tröger ha scritto:
Hello,
I'm opening this ML thread based on the following two forum discussions,
none of which have yielded much resolution yet:
http://en.libreofficeforum.org/node/9850
https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=74332
T
Could you elaborate, please?
On Mon, Dec 29, 2014 at 01:44:51PM +0200, Noel Grandin wrote:
> That smells like a DNS timeout. I suspect that you have some kind of
> network problem.
--
Jens Tröger
http://savage.light-speed.de/
___
LibreOffice mailing l
That smells like a DNS timeout. I suspect that you have some kind of
network problem.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
45 matches
Mail list logo
