Re: Slow motion while editing

[Abdelrazak Younes]

Andre Poenitz wrote:

On Sun, Jul 22, 2007 at 01:44:35PM +0200, [EMAIL PROTECTED] wrote:

Selon [EMAIL PROTECTED]:

Selon Guillaume Pothier [EMAIL PROTECTED]:


Make sure the profiler runs a little bit longer. 20 seconds cumulative
or so. With 4.74 seconds there's a lot of statistical noise.


Done, now 23s.
I updated the file at the same URL:
http://www.dcc.uchile.cl/~gpothier/gprof.out

One question: are you sure that your Qt is compiled with optimisation and debug
disabled? I've read somewhere that it makes a big difference (similar to the
stdlib_debug one). Looks like the QHash searching takes a lot... Same question
for your boost installation.


Looks like we can shave off 3.5% as

[27] 9.20.551.61 44157897 
lyx::frontend::GuiFontMetrics::width(wchar_t) const [27]
1.610.00 88316089/89786389 QHashwchar_t, 
int::findNode(wchar_t const, unsigned int*) const [31]
0.000.00  16/21  QHashwchar_t, 
int::detach_helper() [1984]

looks into the hash twice. The code is

int GuiFontMetrics::width(char_type c) const
{
if (smallcaps_shape_)
return smallcapsWidth(c);

if (!width_cache_.contains(c)) {
if (is_utf16(c))
width_cache_.insert(c, 
metrics_.width(ucs4_to_qchar(c)));
else
width_cache_.insert(c, 
metrics_.width(toqstr(docstring(1,c;
}

return width_cache_.value(c);
}


Something like

int GuiFontMetrics::width(char_type c) const
{
if (smallcaps_shape_)
return smallcapsWidth(c);

int w = width_cache_.value(c, WHATEVER);
if (w != WHATEVER)
return w;

if (is_utf16(c))
w = metrics_.width(ucs4_to_qchar(c);
else
w = metrics_.width(toqstr(docstring(1, c));  // ***

width_cache_.insert(c, w);
return w;
}

should do.


I've done that change, thanks.



And, of course, the line marked *** does not look overly efficient as
well.


I know but it happens only for the very rare case when one need a utf32 
char, and it happens only once of course.


Abdel.

Re: Slow motion while editing

[Abdelrazak Younes]

Andre Poenitz wrote:

On Sun, Jul 22, 2007 at 01:44:35PM +0200, [EMAIL PROTECTED] wrote:

Selon [EMAIL PROTECTED]:

Selon Guillaume Pothier <[EMAIL PROTECTED]>:


Make sure the profiler runs a little bit longer. 20 seconds cumulative
or so. With 4.74 seconds there's a lot of statistical noise.


Done, now 23s.
I updated the file at the same URL:
http://www.dcc.uchile.cl/~gpothier/gprof.out

One question: are you sure that your Qt is compiled with optimisation and debug
disabled? I've read somewhere that it makes a big difference (similar to the
stdlib_debug one). Looks like the QHash searching takes a lot... Same question
for your boost installation.


Looks like we can shave off 3.5% as

[27] 9.20.551.61 44157897 
lyx::frontend::GuiFontMetrics::width(wchar_t) const [27]
1.610.00 88316089/89786389 QHash::findNode(wchar_t const&, unsigned int*) const [31]
0.000.00  16/21  QHash::detach_helper() [1984]

looks into the hash twice. The code is

int GuiFontMetrics::width(char_type c) const
{
if (smallcaps_shape_)
return smallcapsWidth(c);

if (!width_cache_.contains(c)) {
if (is_utf16(c))
width_cache_.insert(c, 
metrics_.width(ucs4_to_qchar(c)));
else
width_cache_.insert(c, 
metrics_.width(toqstr(docstring(1,c;
}

return width_cache_.value(c);
}


Something like

int GuiFontMetrics::width(char_type c) const
{
if (smallcaps_shape_)
return smallcapsWidth(c);

int w = width_cache_.value(c, WHATEVER);
if (w != WHATEVER)
return w;

if (is_utf16(c))
w = metrics_.width(ucs4_to_qchar(c);
else
w = metrics_.width(toqstr(docstring(1, c));  // ***

width_cache_.insert(c, w);
return w;
}

should do.


I've done that change, thanks.



And, of course, the line marked *** does not look overly efficient as
well.


I know but it happens only for the very rare case when one need a utf32 
char, and it happens only once of course.


Abdel.

Re: Slow motion while editing

[Koji Yokota]

[EMAIL PROTECTED] wrote:

Selon [EMAIL PROTECTED]:
  

Selon Guillaume Pothier [EMAIL PROTECTED]:


Make sure the profiler runs a little bit longer. 20 seconds cumulative
or so. With 4.74 seconds there's a lot of statistical noise

Done, now 23s.
I updated the file at the same URL:
http://www.dcc.uchile.cl/~gpothier/gprof.out
  

One question: are you sure that your Qt is compiled with optimisation and debug
disabled? I've read somewhere that it makes a big difference (similar to the
stdlib_debug one). Looks like the QHash searching takes a lot... Same question
for your boost installation.

Abdel.
  
On some systems, build of qt passes the -g option to the c++ compiler 
by default (which was true for me). However, removing it (pass 
--separate-debug-info=no explicitly to configure) didn't improve the 
performance. Its configure has the following code:


 CFG_SEPARATE_DEBUG_INFO=auto

 ...

 # auto-detect support for separate debug info in objcopy
 if [ $CFG_SEPARATE_DEBUG_INFO != no ]  [ $CFG_SHARED = yes 
]; then
 TEST_COMPILER_CFLAGS=`getQMakeConf $XQMAKESPEC | sed -n -e 
's%QMAKE_CFLAGS

 [^_].*=%%p' | tr '\n' ' '`
 TEST_COMPILER_CXXFLAGS=`getQMakeConf $XQMAKESPEC | sed -n -e 
's%QMAKE_CXXF

 LAGS[^_].*=%%p' | tr '\n' ' '`
 TEST_CXX_COMPILER=`getQMakeConf $XQMAKESPEC | grep 
^QMAKE_CXX[^_A-Z0-9]

 | sed s%.* *= *\(.*\)$%\1% | tr '\n' ' '`
 COMPILER_WITH_FLAGS=$TEST_CXX_COMPILER $TEST_COMPILER_CXXFLAGS
 COMPILER_WITH_FLAGS=`echo $COMPILER_WITH_FLAGS | sed -e 
s%\\$\\$QMAKE_CFL

 AGS%$TEST_COMPILER_CFLAGS%`
 if $unixtests/objcopy.test $COMPILER_WITH_FLAGS 
$OPT_VERBOSE; then

CFG_SEPARATE_DEBUG_INFO=no
 else
case $PLATFORM in
hpux-*)
# binutils on HP-UX is buggy; default to no.
CFG_SEPARATE_DEBUG_INFO=no
;;
*)
CFG_SEPARATE_DEBUG_INFO=yes
;;
esac
 fi
 fi

 ...

 if [ $CFG_SEPARATE_DEBUG_INFO = yes ]; then
 QMakeVar add QMAKE_CFLAGS -g
 QMakeVar add QMAKE_CXXFLAGS -g
 QMAKE_CONFIG=$QMAKE_CONFIG separate_debug_info
 fi


Koji

Re: Slow motion while editing

[Koji Yokota]

Koji Yokota wrote:
On some systems, build of qt passes the -g option to the c++ 
compiler by default (which was true for me). However, removing it 
(pass --separate-debug-info=no explicitly to configure) didn't improve 
the performance. Its configure has the following code:


This doesn't seem to be related. qt4 strips out the debugging symbols 
from the resulting libraries and executables to separate files with no 
running cost.

Re: Slow motion while editing

[Guillaume Pothier]

Hmmm... is there a way I can tell it from the executables? I installed
those with my Linux distribution (Ubuntu) so I guess they come with
debugging disables, but I'd like to verify.
g

On 7/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Selon [EMAIL PROTECTED]:
 Selon Guillaume Pothier [EMAIL PROTECTED]:

  
   Make sure the profiler runs a little bit longer. 20 seconds cumulative
   or so. With 4.74 seconds there's a lot of statistical noise.
  
 
  Done, now 23s.
  I updated the file at the same URL:
  http://www.dcc.uchile.cl/~gpothier/gprof.out

One question: are you sure that your Qt is compiled with optimisation and debug
disabled? I've read somewhere that it makes a big difference (similar to the
stdlib_debug one). Looks like the QHash searching takes a lot... Same question
for your boost installation.

Abdel.

Re: Slow motion while editing

[Koji Yokota]

Koji Yokota wrote:
I suspect this may be a problem of qt4 (or may not), as there is a 
small time lag to open a menu in qt4 compared to qt3 (although this 
itself is not too slow to be a problem).


Another qt4 program texmaker ( http://www.xm1math.net/texmaker/ ) is 
running well at my place. It's as fast as lyx-1.4.x. So, this is not a 
problem of qt4.

Re: Slow motion while editing

[Koji Yokota]

[EMAIL PROTECTED] wrote:

Selon [EMAIL PROTECTED]:
  

Selon Guillaume Pothier <[EMAIL PROTECTED]>:


Make sure the profiler runs a little bit longer. 20 seconds cumulative
or so. With 4.74 seconds there's a lot of statistical noise

Done, now 23s.
I updated the file at the same URL:
http://www.dcc.uchile.cl/~gpothier/gprof.out
  

One question: are you sure that your Qt is compiled with optimisation and debug
disabled? I've read somewhere that it makes a big difference (similar to the
stdlib_debug one). Looks like the QHash searching takes a lot... Same question
for your boost installation.

Abdel.
  
On some systems, build of qt passes the "-g" option to the c++ compiler 
by default (which was true for me). However, removing it (pass 
--separate-debug-info=no explicitly to configure) didn't improve the 
performance. Its configure has the following code:


> CFG_SEPARATE_DEBUG_INFO=auto
>
> ...
>
> # auto-detect support for separate debug info in objcopy
> if [ "$CFG_SEPARATE_DEBUG_INFO" != "no" ] && [ "$CFG_SHARED" = "yes" 
]; then
> TEST_COMPILER_CFLAGS=`getQMakeConf "$XQMAKESPEC" | sed -n -e 
's%QMAKE_CFLAGS

> [^_].*=%%p' | tr '\n' ' '`
> TEST_COMPILER_CXXFLAGS=`getQMakeConf "$XQMAKESPEC" | sed -n -e 
's%QMAKE_CXXF

> LAGS[^_].*=%%p' | tr '\n' ' '`
> TEST_CXX_COMPILER=`getQMakeConf "$XQMAKESPEC" | grep 
"^QMAKE_CXX[^_A-Z0-9]"

> | sed "s%.* *= *\(.*\)$%\1%" | tr '\n' ' '`
> COMPILER_WITH_FLAGS="$TEST_CXX_COMPILER $TEST_COMPILER_CXXFLAGS"
> COMPILER_WITH_FLAGS=`echo "$COMPILER_WITH_FLAGS" | sed -e 
"s%\\$\\$QMAKE_CFL

> AGS%$TEST_COMPILER_CFLAGS%"`
> if "$unixtests/objcopy.test" "$COMPILER_WITH_FLAGS" 
"$OPT_VERBOSE"; then

>CFG_SEPARATE_DEBUG_INFO=no
> else
>case "$PLATFORM" in
>hpux-*)
># binutils on HP-UX is buggy; default to no.
>CFG_SEPARATE_DEBUG_INFO=no
>;;
>*)
>CFG_SEPARATE_DEBUG_INFO=yes
>;;
>esac
> fi
> fi
>
> ...
>
> if [ "$CFG_SEPARATE_DEBUG_INFO" = "yes" ]; then
> QMakeVar add QMAKE_CFLAGS -g
> QMakeVar add QMAKE_CXXFLAGS -g
> QMAKE_CONFIG="$QMAKE_CONFIG separate_debug_info"
> fi


Koji

Re: Slow motion while editing

[Koji Yokota]

Koji Yokota wrote:
On some systems, build of qt passes the "-g" option to the c++ 
compiler by default (which was true for me). However, removing it 
(pass --separate-debug-info=no explicitly to configure) didn't improve 
the performance. Its configure has the following code:


This doesn't seem to be related. qt4 strips out the debugging symbols 
from the resulting libraries and executables to separate files with no 
running cost.

Re: Slow motion while editing

[Guillaume Pothier]

Hmmm... is there a way I can tell it from the executables? I installed
those with my Linux distribution (Ubuntu) so I guess they come with
debugging disables, but I'd like to verify.
g

On 7/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Selon [EMAIL PROTECTED]:
> Selon Guillaume Pothier <[EMAIL PROTECTED]>:
>
> > >
> > > Make sure the profiler runs a little bit longer. 20 seconds cumulative
> > > or so. With 4.74 seconds there's a lot of statistical noise.
> > >
> >
> > Done, now 23s.
> > I updated the file at the same URL:
> > http://www.dcc.uchile.cl/~gpothier/gprof.out

One question: are you sure that your Qt is compiled with optimisation and debug
disabled? I've read somewhere that it makes a big difference (similar to the
stdlib_debug one). Looks like the QHash searching takes a lot... Same question
for your boost installation.

Abdel.

Re: Slow motion while editing

[Koji Yokota]

Koji Yokota wrote:
I suspect this may be a problem of qt4 (or may not), as there is a 
small time lag to open a menu in qt4 compared to qt3 (although this 
itself is not too slow to be a problem).


Another qt4 program texmaker ( http://www.xm1math.net/texmaker/ ) is 
running well at my place. It's as fast as lyx-1.4.x. So, this is not a 
problem of qt4.

Re: Slow motion while editing

[Darren Freeman]

On Fri, 2007-07-20 at 10:46 +0200, Abdelrazak Younes wrote:
 Darren Freeman wrote:
  On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
  I am sorry to hear that but we have no way to help you without nothing 
  where the slowdown is. We need profile results! So, if you want to have 
  a faster 1.5, please try to provide some.
  
  I would love that but I'm currently without income owing to my thesis
  not being written yet :)
 
 If you can find the time to compile from a svn, compiling with profiling 
 enabled is supposed to be easy on linux (with --enable-profile or 
 something).

I have never in my life profiled anything so if you have a howto you can
recommend, I'll skim it. Otherwise it has to wait.

Also I'm planning to learn how to use Valgrind so maybe breaking LyX
would be good practise too.
 
  I suspect it is related to the size of the document.
 
 No, it shouldn't be.

It seems to correlate with the size of the current paragraph though.

Have fun,
Darren

Re: Slow motion while editing

[younes . a]

Selon Guillaume Pothier [EMAIL PROTECTED]:

 
  Make sure the profiler runs a little bit longer. 20 seconds cumulative
  or so. With 4.74 seconds there's a lot of statistical noise.
 

 Done, now 23s.
 I updated the file at the same URL:
 http://www.dcc.uchile.cl/~gpothier/gprof.out

Looks like the following four (at metrics calculation time) are at fault:

2.95 lyx::TextMetrics::rowBreakPoint(int, int, lyx::Row) const [18]
2.91 lyx::TextMetrics::setRowWidth(int, int, lyx::Row) const [19]
2.94 lyx::InsetMathHull::metrics(lyx::MetricsInfo, lyx::Dimension) const [20]
1.07 lyx::TextMetrics::setHeightOfRow(int, lyx::Row) [41]

The painting takes the rest:
6.19 lyx::paintText

splitted in:
1.84 paintPar(lyx::PainterInfo, lyx::Text const, int, int, int, bool)
1.40 RowPainter::paintFromPos(int) cycle 6 [33]
1.17 RowPainter::paintInset(int, lyx::Font const)
0.78 RowPainter::paintText()

I cannot do much right now but will try to optimize when I am back.

Abdel.

Re: Slow motion while editing

[younes . a]

Selon [EMAIL PROTECTED]:
 Selon Guillaume Pothier [EMAIL PROTECTED]:

  
   Make sure the profiler runs a little bit longer. 20 seconds cumulative
   or so. With 4.74 seconds there's a lot of statistical noise.
  
 
  Done, now 23s.
  I updated the file at the same URL:
  http://www.dcc.uchile.cl/~gpothier/gprof.out

One question: are you sure that your Qt is compiled with optimisation and debug
disabled? I've read somewhere that it makes a big difference (similar to the
stdlib_debug one). Looks like the QHash searching takes a lot... Same question
for your boost installation.

Abdel.

Re: Slow motion while editing

[Andre Poenitz]

On Sun, Jul 22, 2007 at 01:40:19PM +0200, [EMAIL PROTECTED] wrote:
 Selon Guillaume Pothier [EMAIL PROTECTED]:
 
  
   Make sure the profiler runs a little bit longer. 20 seconds cumulative
   or so. With 4.74 seconds there's a lot of statistical noise.
  
 
  Done, now 23s.
  I updated the file at the same URL:
  http://www.dcc.uchile.cl/~gpothier/gprof.out
 
 Looks like the following four (at metrics calculation time) are at fault:
 
 2.95 lyx::TextMetrics::rowBreakPoint(int, int, lyx::Row) const [18]
 2.91 lyx::TextMetrics::setRowWidth(int, int, lyx::Row) const [19]
 2.94 lyx::InsetMathHull::metrics(lyx::MetricsInfo, lyx::Dimension) const 
 [20]
 1.07 lyx::TextMetrics::setHeightOfRow(int, lyx::Row) [41]
 
 The painting takes the rest:
 6.19 lyx::paintText
 
 splitted in:
 1.84 paintPar(lyx::PainterInfo, lyx::Text const, int, int, int, bool)
 1.40 RowPainter::paintFromPos(int) cycle 6 [33]
 1.17 RowPainter::paintInset(int, lyx::Font const)
 0.78 RowPainter::paintText()

But that's on par with what we had even in 1.2.x. Note that even
completely removing those would speed up LyX by a 'mere' 20% or so.

Andre' 

Re: Slow motion while editing

[Andre Poenitz]

On Sun, Jul 22, 2007 at 01:44:35PM +0200, [EMAIL PROTECTED] wrote:
 Selon [EMAIL PROTECTED]:
  Selon Guillaume Pothier [EMAIL PROTECTED]:
 
   
Make sure the profiler runs a little bit longer. 20 seconds cumulative
or so. With 4.74 seconds there's a lot of statistical noise.
   
  
   Done, now 23s.
   I updated the file at the same URL:
   http://www.dcc.uchile.cl/~gpothier/gprof.out
 
 One question: are you sure that your Qt is compiled with optimisation and 
 debug
 disabled? I've read somewhere that it makes a big difference (similar to the
 stdlib_debug one). Looks like the QHash searching takes a lot... Same question
 for your boost installation.

Looks like we can shave off 3.5% as

[27] 9.20.551.61 44157897 
lyx::frontend::GuiFontMetrics::width(wchar_t) const [27]
1.610.00 88316089/89786389 QHashwchar_t, 
int::findNode(wchar_t const, unsigned int*) const [31]
0.000.00  16/21  QHashwchar_t, 
int::detach_helper() [1984]

looks into the hash twice. The code is

int GuiFontMetrics::width(char_type c) const
{
if (smallcaps_shape_)
return smallcapsWidth(c);

if (!width_cache_.contains(c)) {
if (is_utf16(c))
width_cache_.insert(c, 
metrics_.width(ucs4_to_qchar(c)));
else
width_cache_.insert(c, 
metrics_.width(toqstr(docstring(1,c;
}

return width_cache_.value(c);
}


Something like

int GuiFontMetrics::width(char_type c) const
{
if (smallcaps_shape_)
return smallcapsWidth(c);

int w = width_cache_.value(c, WHATEVER);
if (w != WHATEVER)
return w;

if (is_utf16(c))
w = metrics_.width(ucs4_to_qchar(c);
else
w = metrics_.width(toqstr(docstring(1, c));  // ***

width_cache_.insert(c, w);
return w;
}

should do.

And, of course, the line marked *** does not look overly efficient as
well.

Andre'

PS: Nice profile now, Guillaume.

Re: Slow motion while editing

[Darren Freeman]

On Fri, 2007-07-20 at 10:46 +0200, Abdelrazak Younes wrote:
> Darren Freeman wrote:
> > On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
> >> I am sorry to hear that but we have no way to help you without nothing 
> >> where the slowdown is. We need profile results! So, if you want to have 
> >> a faster 1.5, please try to provide some.
> > 
> > I would love that but I'm currently without income owing to my thesis
> > not being written yet :)
> 
> If you can find the time to compile from a svn, compiling with profiling 
> enabled is supposed to be easy on linux (with --enable-profile or 
> something).

I have never in my life profiled anything so if you have a howto you can
recommend, I'll skim it. Otherwise it has to wait.

Also I'm planning to learn how to use Valgrind so maybe breaking LyX
would be good practise too.
 
> > I suspect it is related to the size of the document.
> 
> No, it shouldn't be.

It seems to correlate with the size of the current paragraph though.

Have fun,
Darren

Re: Slow motion while editing

[younes . a]

Selon Guillaume Pothier <[EMAIL PROTECTED]>:

> >
> > Make sure the profiler runs a little bit longer. 20 seconds cumulative
> > or so. With 4.74 seconds there's a lot of statistical noise.
> >
>
> Done, now 23s.
> I updated the file at the same URL:
> http://www.dcc.uchile.cl/~gpothier/gprof.out

Looks like the following four (at metrics calculation time) are at fault:

2.95 lyx::TextMetrics::rowBreakPoint(int, int, lyx::Row&) const [18]
2.91 lyx::TextMetrics::setRowWidth(int, int, lyx::Row&) const [19]
2.94 lyx::InsetMathHull::metrics(lyx::MetricsInfo&, lyx::Dimension&) const [20]
1.07 lyx::TextMetrics::setHeightOfRow(int, lyx::Row&) [41]

The painting takes the rest:
6.19 lyx::paintText

splitted in:
1.84 paintPar(lyx::PainterInfo&, lyx::Text const&, int, int, int, bool)
1.40 RowPainter::paintFromPos(int&)  [33]
1.17 RowPainter::paintInset(int, lyx::Font const&)
0.78 RowPainter::paintText()

I cannot do much right now but will try to optimize when I am back.

Abdel.

Re: Slow motion while editing

[younes . a]

Selon [EMAIL PROTECTED]:
> Selon Guillaume Pothier <[EMAIL PROTECTED]>:
>
> > >
> > > Make sure the profiler runs a little bit longer. 20 seconds cumulative
> > > or so. With 4.74 seconds there's a lot of statistical noise.
> > >
> >
> > Done, now 23s.
> > I updated the file at the same URL:
> > http://www.dcc.uchile.cl/~gpothier/gprof.out

One question: are you sure that your Qt is compiled with optimisation and debug
disabled? I've read somewhere that it makes a big difference (similar to the
stdlib_debug one). Looks like the QHash searching takes a lot... Same question
for your boost installation.

Abdel.

Re: Slow motion while editing

[Andre Poenitz]

On Sun, Jul 22, 2007 at 01:40:19PM +0200, [EMAIL PROTECTED] wrote:
> Selon Guillaume Pothier <[EMAIL PROTECTED]>:
> 
> > >
> > > Make sure the profiler runs a little bit longer. 20 seconds cumulative
> > > or so. With 4.74 seconds there's a lot of statistical noise.
> > >
> >
> > Done, now 23s.
> > I updated the file at the same URL:
> > http://www.dcc.uchile.cl/~gpothier/gprof.out
> 
> Looks like the following four (at metrics calculation time) are at fault:
> 
> 2.95 lyx::TextMetrics::rowBreakPoint(int, int, lyx::Row&) const [18]
> 2.91 lyx::TextMetrics::setRowWidth(int, int, lyx::Row&) const [19]
> 2.94 lyx::InsetMathHull::metrics(lyx::MetricsInfo&, lyx::Dimension&) const 
> [20]
> 1.07 lyx::TextMetrics::setHeightOfRow(int, lyx::Row&) [41]
> 
> The painting takes the rest:
> 6.19 lyx::paintText
> 
> splitted in:
> 1.84 paintPar(lyx::PainterInfo&, lyx::Text const&, int, int, int, bool)
> 1.40 RowPainter::paintFromPos(int&)  [33]
> 1.17 RowPainter::paintInset(int, lyx::Font const&)
> 0.78 RowPainter::paintText()

But that's on par with what we had even in 1.2.x. Note that even
completely removing those would speed up LyX by a 'mere' 20% or so.

Andre' 

Re: Slow motion while editing

[Andre Poenitz]

On Sun, Jul 22, 2007 at 01:44:35PM +0200, [EMAIL PROTECTED] wrote:
> Selon [EMAIL PROTECTED]:
> > Selon Guillaume Pothier <[EMAIL PROTECTED]>:
> >
> > > >
> > > > Make sure the profiler runs a little bit longer. 20 seconds cumulative
> > > > or so. With 4.74 seconds there's a lot of statistical noise.
> > > >
> > >
> > > Done, now 23s.
> > > I updated the file at the same URL:
> > > http://www.dcc.uchile.cl/~gpothier/gprof.out
> 
> One question: are you sure that your Qt is compiled with optimisation and 
> debug
> disabled? I've read somewhere that it makes a big difference (similar to the
> stdlib_debug one). Looks like the QHash searching takes a lot... Same question
> for your boost installation.

Looks like we can shave off 3.5% as

[27] 9.20.551.61 44157897 
lyx::frontend::GuiFontMetrics::width(wchar_t) const [27]
1.610.00 88316089/89786389 QHash::findNode(wchar_t const&, unsigned int*) const [31]
0.000.00  16/21  QHash::detach_helper() [1984]

looks into the hash twice. The code is

int GuiFontMetrics::width(char_type c) const
{
if (smallcaps_shape_)
return smallcapsWidth(c);

if (!width_cache_.contains(c)) {
if (is_utf16(c))
width_cache_.insert(c, 
metrics_.width(ucs4_to_qchar(c)));
else
width_cache_.insert(c, 
metrics_.width(toqstr(docstring(1,c;
}

return width_cache_.value(c);
}


Something like

int GuiFontMetrics::width(char_type c) const
{
if (smallcaps_shape_)
return smallcapsWidth(c);

int w = width_cache_.value(c, WHATEVER);
if (w != WHATEVER)
return w;

if (is_utf16(c))
w = metrics_.width(ucs4_to_qchar(c);
else
w = metrics_.width(toqstr(docstring(1, c));  // ***

width_cache_.insert(c, w);
return w;
}

should do.

And, of course, the line marked *** does not look overly efficient as
well.

Andre'

PS: Nice profile now, Guillaume.

Re: Slow motion while editing

[Andre Poenitz]

On Fri, Jul 20, 2007 at 02:45:47PM -0400, Guillaume Pothier wrote:
 Here are the profiling results: http://www.dcc.uchile.cl/~gpothier/gprof.out
 This was using the document I already sent, typing random stuff within
 floats, in paragraphs containing math insets, and in new paragraphs.
 
 Please tell me if I can provide more info.

Make sure the profiler runs a little bit longer. 20 seconds cumulative
or so. With 4.74 seconds there's a lot of statistical noise.

There's still a bit of STL stuff fairly high uup in the list. Wonder
why...

Andre'

Re: Slow motion while editing

[Guillaume Pothier]

Make sure the profiler runs a little bit longer. 20 seconds cumulative
or so. With 4.74 seconds there's a lot of statistical noise.



Done, now 23s.
I updated the file at the same URL: http://www.dcc.uchile.cl/~gpothier/gprof.out

Re: Slow motion while editing

[Andre Poenitz]

On Fri, Jul 20, 2007 at 02:45:47PM -0400, Guillaume Pothier wrote:
> Here are the profiling results: http://www.dcc.uchile.cl/~gpothier/gprof.out
> This was using the document I already sent, typing random stuff within
> floats, in paragraphs containing math insets, and in new paragraphs.
> 
> Please tell me if I can provide more info.

Make sure the profiler runs a little bit longer. 20 seconds cumulative
or so. With 4.74 seconds there's a lot of statistical noise.

There's still a bit of STL stuff fairly high uup in the list. Wonder
why...

Andre'

Re: Slow motion while editing

[Guillaume Pothier]

Make sure the profiler runs a little bit longer. 20 seconds cumulative
or so. With 4.74 seconds there's a lot of statistical noise.



Done, now 23s.
I updated the file at the same URL: http://www.dcc.uchile.cl/~gpothier/gprof.out

Re: Slow motion while editing

[Abdelrazak Younes]

Guillaume Pothier wrote:

Abdel, I tried your patch and it actually makes things noticeably slower!


Too bad! I guess the performance depends on the pixmap painting 
capabilities of your system. On Windows and I think Mac, it is 
definitely faster.


Abdel.

Re: Slow motion while editing

[Abdelrazak Younes]

Darren Freeman wrote:

On Thu, 2007-07-19 at 22:27 +0200, Abdelrazak Younes wrote:

Guillaume Pothier wrote:
Ok, I also tried with --disable-stdlib-debug and I don't notice any 
difference.

Could you please try this patch?


No noticeable effect, on the same document both with and without the
patch, scrolling lag is around 0.5 s, and mashing the keyboard with
maybe 30 chars into an empty paragraph, gave a couple of s of catchup
time.


I am sorry to hear that but we have no way to help you without nothing 
where the slowdown is. We need profile results! So, if you want to have 
a faster 1.5, please try to provide some.


Abdel.

Re: Slow motion while editing

[Darren Freeman]

On Fri, 2007-07-20 at 10:29 +0200, Abdelrazak Younes wrote:
 Guillaume Pothier wrote:
  Abdel, I tried your patch and it actually makes things noticeably slower!
 
 Too bad! I guess the performance depends on the pixmap painting 
 capabilities of your system. On Windows and I think Mac, it is 
 definitely faster.

What does that say about our systems... that Win and Mac require help to
run fast, or that X11 can't be helped :)

Have fun,
Darren

Re: Slow motion while editing

[Darren Freeman]

On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
 I am sorry to hear that but we have no way to help you without nothing 
 where the slowdown is. We need profile results! So, if you want to have 
 a faster 1.5, please try to provide some.

I would love that but I'm currently without income owing to my thesis
not being written yet :)

I suspect it is related to the size of the document. Profiling on my
thesis would be a good idea I'm sure, but I have to find the time...
Unfortunately in cases like this the user isn't keen to publish their
document for the mailing list either :)

Shouldn't we have a suite of test documents? Such as generating a really
big LyX file using for loops to populate the paragraphs, or including
heaps of floats, insets, etc.

Have fun,
Darren

Re: Slow motion while editing

[Michael Gerz]

Darren Freeman schrieb:

On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
  
I am sorry to hear that but we have no way to help you without nothing 
where the slowdown is. We need profile results! So, if you want to have 
a faster 1.5, please try to provide some.



Unfortunately in cases like this the user isn't keen to publish their
document for the mailing list either :)
  
You could make your document unreable, e.g., by replacing all b, c, 
... by a, while preserving its structure.


Michael

Re: Slow motion while editing

[Abdelrazak Younes]

Darren Freeman wrote:

On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without nothing 
where the slowdown is. We need profile results! So, if you want to have 
a faster 1.5, please try to provide some.


I would love that but I'm currently without income owing to my thesis
not being written yet :)


If you can find the time to compile from a svn, compiling with profiling 
enabled is supposed to be easy on linux (with --enable-profile or 
something).


I suspect it is related to the size of the document.


No, it shouldn't be.

Abdel.

Re: Slow motion while editing

[Pavel Sanda]

 I don't know if it is related but with the svn version compiled
 yesterday there  is a very noticeable lag in typing. Attached is a
 file that is causing problems.

i have tried your file with rc2 (on linux) and dont see any typing lag.
cant try it on svn now - but is it with rc2 better for you ?

pavel

Re: Slow motion while editing

[Guillaume Pothier]

If you can find the time to compile from a svn, compiling with profiling
enabled is supposed to be easy on linux (with --enable-profile or
something).


Ok I'll try it.
Where are profiling results going to be output?
g

Re: Slow motion while editing

[Pavel Sanda]

 Where are profiling results going to be output?

i thought gprof should be used.
however i didnt succeeded when running it - lyx
immediately ends and gprof makes only analysis
of that run. maybe some additional parameter
sould be given, but i dont know which one.

pavel

Re: Slow motion while editing

[Koji Yokota]

Abdelrazak Younes wrote:

Darren Freeman wrote:

On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without 
nothing where the slowdown is. We need profile results! So, if you 
want to have a faster 1.5, please try to provide some.


I would love that but I'm currently without income owing to my thesis
not being written yet :)


If you can find the time to compile from a svn, compiling with 
profiling enabled is supposed to be easy on linux (with 
--enable-profile or something).
I'm incurring the same problem as Darren on svn (on FreeBSD). There is 
already a big time lag to type on a new document, and as the length of 
the document grows, the time lag becomes unbearable.


On a new document, typing can catch up if you type meaningful sentences, 
but it cannot catch up random typing. After ten seconds of random 
typing, you have to wait probably more than five seconds to complete. 
This may not be a problem to type English, but problematic in CJK 
environment, because they use Input Method to convert typed keys to a 
sentence, and a relatively long sentence is fed to lyx *at once* (but 
anyway as a document becomes longer, it also becomes unbearable in English).


I tried to write a small paper, but as the paper becomes longer, I found 
out the time lag makes lyx to an unusable level.


I suspect this may be a problem of qt4 (or may not), as there is a small 
time lag to open a menu in qt4 compared to qt3 (although this itself is 
not too slow to be a problem). Unfortunately, I find no error message 
either. In case, the debug message with random typing is as follows.


The tested machine has Xeon (nocona) 3GHz.

Koji

--
ParPosCache contains:
Text:0x92921bc
Paragraph 0: asdf;lkasj has point 0,36
Paragraph 1: asdprov iu has point 0,146
InsetCache contains:
dispatch msg is
SelfInsert arg[`d']
virtual void lyx::frontend::GuiWorkArea::keyPressEvent(QKeyEvent*) 
count=1 text=f isAutoRepeat=0 key=70

Setting key to 70, f
KeySym is f
isOK is 1
isMod is 0
void lyx::LyXFunc::processKeySym(lyx::KeySymbolPtr, 
lyx::key_modifier::state) action first set to [85]
void lyx::LyXFunc::processKeySym(lyx::KeySymbolPtr, 
lyx::key_modifier::state)action now set to [85]
void lyx::LyXFunc::processKeySym(lyx::KeySymbolPtr, 
lyx::key_modifier::state) Key [action=85][F]


LyXFunc::dispatch: cmd:  action: 85 arg: 'f' x: 0 y: 0
void lyx::Cursor::dispatch(const lyx::FuncRequest) cmd:  action: 85 
arg: 'f' x: 0 y: 0


cursor:| anchor:
inset: 0x929219c idx: 0 par: 1 pos: 116 | inset: 0x929219c idx: 0 par: 
1 pos: 116

selection: 0 x_target: -1

Cursor::dispatch: cmd:  action: 85 arg: 'f' x: 0 y: 0

cursor:| anchor:
inset: 0x929219c idx: 0 par: 1 pos: 116 | inset: 0x929219c idx: 0 par: 
1 pos: 116

selection: 0 x_target: -1

virtual void lyx::InsetText::doDispatch(lyx::Cursor, lyx::FuncRequest) 
[ cmd.action = 85]

Text::dispatch: cmd:  action: 85 arg: 'f' x: 0 y: 0
bool lyx::BufferView::update(lyx::Update::flags)[fitcursor = 1, 
forceupdate = 0, singlepar = 4]  buffer: 0x9282c00

BufferView::update
void lyx::BufferView::updateMetrics(bool) y1: 130 y2: 194 pit1: 1 pit2: 
1 npit: 2 singlepar: 1size: 2

BufferView::updateMetrics
ParPosCache contains:
Text:0x92921bc
Paragraph 0: asdf;lkasj has point 0,36
Paragraph 1: asdprov iu has point 0,146
InsetCache contains:
void lyx::BufferView::updateScrollbar() Updating scrollbar: height: 2 
curr par: 1 default height 24

WorkArea::redraw screen
#draw fdsafdsafdsafdsaasdfdsaadfasdf at 12,168
.

Re: Slow motion while editing

[Andre Poenitz]

On Fri, Jul 20, 2007 at 06:35:52PM +1000, Darren Freeman wrote:
 On Fri, 2007-07-20 at 10:29 +0200, Abdelrazak Younes wrote:
  Guillaume Pothier wrote:
   Abdel, I tried your patch and it actually makes things noticeably slower!
  
  Too bad! I guess the performance depends on the pixmap painting 
  capabilities of your system. On Windows and I think Mac, it is 
  definitely faster.
 
 What does that say about our systems... that Win and Mac require help to
 run fast, or that X11 can't be helped :)

The problem here is that the drawing systems are incompatible in so
far as making something fast on one system has a certain potential to
slow down other systems. On X11, and most notably on remote X11,
performance is often limited by the communication speed of client and
server, and increasing that requires sending little data and don't do
anything requiring synchronous feed back. Otoh on Windows one gets
usually pretty good (text drawing) results by doing everything locally
and sending the final result in one chunk to the graphics card.

Andre'

Re: Slow motion while editing

[Guillaume Pothier]

Here are the profiling results: http://www.dcc.uchile.cl/~gpothier/gprof.out
This was using the document I already sent, typing random stuff within
floats, in paragraphs containing math insets, and in new paragraphs.

Please tell me if I can provide more info.
g

On 7/20/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:

Darren Freeman wrote:
 On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
 I am sorry to hear that but we have no way to help you without nothing
 where the slowdown is. We need profile results! So, if you want to have
 a faster 1.5, please try to provide some.

 I would love that but I'm currently without income owing to my thesis
 not being written yet :)

If you can find the time to compile from a svn, compiling with profiling
enabled is supposed to be easy on linux (with --enable-profile or
something).

 I suspect it is related to the size of the document.

No, it shouldn't be.

Abdel.

Re: Slow motion while editing

[Peter Kümmel]

Guillaume Pothier wrote:
 Here are the profiling results:
 http://www.dcc.uchile.cl/~gpothier/gprof.out
 This was using the document I already sent, typing random stuff within
 floats, in paragraphs containing math insets, and in new paragraphs.
 
 Please tell me if I can provide more info.
 g

From your file:

 .11  0.86 0.16 16862068 0.00 0.00  
 __gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorlyx::Paragraph::Pimpl::FontTable*,
  __gnu_norm::vectorlyx::Paragraph::Pimpl::FontTable, 
 std::allocatorlyx::Paragraph::

Seems you have still enabled stdlib-debug?
Have you really used --disable-stdlib-debug?

Peter

Re: Slow motion while editing

[Guillaume Pothier]

Sorry, I forgot that flag when I compiled with profiling enabled...
I'm compiling with both now, I'll report soon.
g

On 7/20/07, Peter Kümmel [EMAIL PROTECTED] wrote:

Guillaume Pothier wrote:
 Here are the profiling results:
 http://www.dcc.uchile.cl/~gpothier/gprof.out
 This was using the document I already sent, typing random stuff within
 floats, in paragraphs containing math insets, and in new paragraphs.

 Please tell me if I can provide more info.
 g

From your file:

 .11  0.86 0.16 16862068 0.00 0.00  
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorlyx::Paragraph::Pimpl::FontTable*,
 __gnu_norm::vectorlyx::Paragraph::Pimpl::FontTable, std::allocatorlyx::Paragraph::

Seems you have still enabled stdlib-debug?
Have you really used --disable-stdlib-debug?

Peter

Re: Slow motion while editing

[Guillaume Pothier]

Hi, so I compiled lyx with profiling enabled and without debug info,
and I updated the gprof.out (same URL:
http://www.dcc.uchile.cl/~gpothier/gprof.out)
g

On 7/20/07, Peter Kümmel [EMAIL PROTECTED] wrote:

Guillaume Pothier wrote:
 Here are the profiling results:
 http://www.dcc.uchile.cl/~gpothier/gprof.out
 This was using the document I already sent, typing random stuff within
 floats, in paragraphs containing math insets, and in new paragraphs.

 Please tell me if I can provide more info.
 g

From your file:

 .11  0.86 0.16 16862068 0.00 0.00  
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorlyx::Paragraph::Pimpl::FontTable*,
 __gnu_norm::vectorlyx::Paragraph::Pimpl::FontTable, std::allocatorlyx::Paragraph::

Seems you have still enabled stdlib-debug?
Have you really used --disable-stdlib-debug?

Peter

Re: Slow motion while editing

[Abdelrazak Younes]

Guillaume Pothier wrote:

Abdel, I tried your patch and it actually makes things noticeably slower!


Too bad! I guess the performance depends on the pixmap painting 
capabilities of your system. On Windows and I think Mac, it is 
definitely faster.


Abdel.

Re: Slow motion while editing

[Abdelrazak Younes]

Darren Freeman wrote:

On Thu, 2007-07-19 at 22:27 +0200, Abdelrazak Younes wrote:

Guillaume Pothier wrote:
Ok, I also tried with --disable-stdlib-debug and I don't notice any 
difference.

Could you please try this patch?


No noticeable effect, on the same document both with and without the
patch, scrolling lag is around 0.5 s, and mashing the keyboard with
maybe 30 chars into an empty paragraph, gave a couple of s of catchup
time.


I am sorry to hear that but we have no way to help you without nothing 
where the slowdown is. We need profile results! So, if you want to have 
a faster 1.5, please try to provide some.


Abdel.

Re: Slow motion while editing

[Darren Freeman]

On Fri, 2007-07-20 at 10:29 +0200, Abdelrazak Younes wrote:
> Guillaume Pothier wrote:
> > Abdel, I tried your patch and it actually makes things noticeably slower!
> 
> Too bad! I guess the performance depends on the pixmap painting 
> capabilities of your system. On Windows and I think Mac, it is 
> definitely faster.

What does that say about our systems... that Win and Mac require help to
run fast, or that X11 can't be helped :)

Have fun,
Darren

Re: Slow motion while editing

[Darren Freeman]

On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
> I am sorry to hear that but we have no way to help you without nothing 
> where the slowdown is. We need profile results! So, if you want to have 
> a faster 1.5, please try to provide some.

I would love that but I'm currently without income owing to my thesis
not being written yet :)

I suspect it is related to the size of the document. Profiling on my
thesis would be a good idea I'm sure, but I have to find the time...
Unfortunately in cases like this the user isn't keen to publish their
document for the mailing list either :)

Shouldn't we have a suite of test documents? Such as generating a really
big LyX file using for loops to populate the paragraphs, or including
heaps of floats, insets, etc.

Have fun,
Darren

Re: Slow motion while editing

[Michael Gerz]

Darren Freeman schrieb:

On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
  
I am sorry to hear that but we have no way to help you without nothing 
where the slowdown is. We need profile results! So, if you want to have 
a faster 1.5, please try to provide some.



Unfortunately in cases like this the user isn't keen to publish their
document for the mailing list either :)
  
You could make your document unreable, e.g., by replacing all "b", "c", 
... by "a", while preserving its structure.


Michael

Re: Slow motion while editing

[Abdelrazak Younes]

Darren Freeman wrote:

On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without nothing 
where the slowdown is. We need profile results! So, if you want to have 
a faster 1.5, please try to provide some.


I would love that but I'm currently without income owing to my thesis
not being written yet :)


If you can find the time to compile from a svn, compiling with profiling 
enabled is supposed to be easy on linux (with --enable-profile or 
something).


I suspect it is related to the size of the document.


No, it shouldn't be.

Abdel.

Re: Slow motion while editing

[Pavel Sanda]

> I don't know if it is related but with the svn version compiled
> yesterday there  is a very noticeable lag in typing. Attached is a
> file that is causing problems.

i have tried your file with rc2 (on linux) and dont see any typing lag.
cant try it on svn now - but is it with rc2 better for you ?

pavel

Re: Slow motion while editing

[Guillaume Pothier]

If you can find the time to compile from a svn, compiling with profiling
enabled is supposed to be easy on linux (with --enable-profile or
something).


Ok I'll try it.
Where are profiling results going to be output?
g

Re: Slow motion while editing

[Pavel Sanda]

> Where are profiling results going to be output?

i thought gprof should be used.
however i didnt succeeded when running it - lyx
immediately ends and gprof makes only analysis
of that run. maybe some additional parameter
sould be given, but i dont know which one.

pavel

Re: Slow motion while editing

[Koji Yokota]

Abdelrazak Younes wrote:

Darren Freeman wrote:

On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without 
nothing where the slowdown is. We need profile results! So, if you 
want to have a faster 1.5, please try to provide some.


I would love that but I'm currently without income owing to my thesis
not being written yet :)


If you can find the time to compile from a svn, compiling with 
profiling enabled is supposed to be easy on linux (with 
--enable-profile or something).
I'm incurring the same problem as Darren on svn (on FreeBSD). There is 
already a big time lag to type on a new document, and as the length of 
the document grows, the time lag becomes unbearable.


On a new document, typing can catch up if you type meaningful sentences, 
but it cannot catch up random typing. After ten seconds of random 
typing, you have to wait probably more than five seconds to complete. 
This may not be a problem to type English, but problematic in CJK 
environment, because they use Input Method to convert typed keys to a 
sentence, and a relatively long sentence is fed to lyx *at once* (but 
anyway as a document becomes longer, it also becomes unbearable in English).


I tried to write a small paper, but as the paper becomes longer, I found 
out the time lag makes lyx to an unusable level.


I suspect this may be a problem of qt4 (or may not), as there is a small 
time lag to open a menu in qt4 compared to qt3 (although this itself is 
not too slow to be a problem). Unfortunately, I find no error message 
either. In case, the debug message with random typing is as follows.


The tested machine has Xeon (nocona) 3GHz.

Koji

--
ParPosCache contains:
Text:0x92921bc
Paragraph 0: "asdf;lkasj" has point 0,36
Paragraph 1: "asdprov iu" has point 0,146
InsetCache contains:
dispatch msg is
SelfInsert arg[`d']
virtual void lyx::frontend::GuiWorkArea::keyPressEvent(QKeyEvent*) 
count=1 text=f isAutoRepeat=0 key=70

Setting key to 70, f
KeySym is f
isOK is 1
isMod is 0
void lyx::LyXFunc::processKeySym(lyx::KeySymbolPtr, 
lyx::key_modifier::state) action first set to [85]
void lyx::LyXFunc::processKeySym(lyx::KeySymbolPtr, 
lyx::key_modifier::state)action now set to [85]
void lyx::LyXFunc::processKeySym(lyx::KeySymbolPtr, 
lyx::key_modifier::state) Key [action=85][F]


LyXFunc::dispatch: cmd:  action: 85 arg: 'f' x: 0 y: 0
void lyx::Cursor::dispatch(const lyx::FuncRequest&) cmd:  action: 85 
arg: 'f' x: 0 y: 0


cursor:| anchor:
inset: 0x929219c idx: 0 par: 1 pos: 116 | inset: 0x929219c idx: 0 par: 
1 pos: 116

selection: 0 x_target: -1

Cursor::dispatch: cmd:  action: 85 arg: 'f' x: 0 y: 0

cursor:| anchor:
inset: 0x929219c idx: 0 par: 1 pos: 116 | inset: 0x929219c idx: 0 par: 
1 pos: 116

selection: 0 x_target: -1

virtual void lyx::InsetText::doDispatch(lyx::Cursor&, lyx::FuncRequest&) 
[ cmd.action = 85]

Text::dispatch: cmd:  action: 85 arg: 'f' x: 0 y: 0
bool lyx::BufferView::update(lyx::Update::flags)[fitcursor = 1, 
forceupdate = 0, singlepar = 4]  buffer: 0x9282c00

BufferView::update
void lyx::BufferView::updateMetrics(bool) y1: 130 y2: 194 pit1: 1 pit2: 
1 npit: 2 singlepar: 1size: 2

BufferView::updateMetrics
ParPosCache contains:
Text:0x92921bc
Paragraph 0: "asdf;lkasj" has point 0,36
Paragraph 1: "asdprov iu" has point 0,146
InsetCache contains:
void lyx::BufferView::updateScrollbar() Updating scrollbar: height: 2 
curr par: 1 default height 24

WorkArea::redraw screen
#draw fdsafdsafdsafdsaasdfdsaadfasdf at 12,168
.

Re: Slow motion while editing

[Andre Poenitz]

On Fri, Jul 20, 2007 at 06:35:52PM +1000, Darren Freeman wrote:
> On Fri, 2007-07-20 at 10:29 +0200, Abdelrazak Younes wrote:
> > Guillaume Pothier wrote:
> > > Abdel, I tried your patch and it actually makes things noticeably slower!
> > 
> > Too bad! I guess the performance depends on the pixmap painting 
> > capabilities of your system. On Windows and I think Mac, it is 
> > definitely faster.
> 
> What does that say about our systems... that Win and Mac require help to
> run fast, or that X11 can't be helped :)

The problem here is that the drawing systems are "incompatible" in so
far as making something fast on one system has a certain potential to
slow down other systems. On X11, and most notably on remote X11,
performance is often limited by the communication speed of client and
server, and increasing that requires sending little data and don't do
anything requiring synchronous feed back. Otoh on Windows one gets
usually pretty good (text drawing) results by doing everything locally
and sending the final result in one chunk to the graphics card.

Andre'

Re: Slow motion while editing

[Guillaume Pothier]

Here are the profiling results: http://www.dcc.uchile.cl/~gpothier/gprof.out
This was using the document I already sent, typing random stuff within
floats, in paragraphs containing math insets, and in new paragraphs.

Please tell me if I can provide more info.
g

On 7/20/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

Darren Freeman wrote:
> On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
>> I am sorry to hear that but we have no way to help you without nothing
>> where the slowdown is. We need profile results! So, if you want to have
>> a faster 1.5, please try to provide some.
>
> I would love that but I'm currently without income owing to my thesis
> not being written yet :)

If you can find the time to compile from a svn, compiling with profiling
enabled is supposed to be easy on linux (with --enable-profile or
something).
>
> I suspect it is related to the size of the document.

No, it shouldn't be.

Abdel.

Re: Slow motion while editing

[Peter Kümmel]

Guillaume Pothier wrote:
> Here are the profiling results:
> http://www.dcc.uchile.cl/~gpothier/gprof.out
> This was using the document I already sent, typing random stuff within
> floats, in paragraphs containing math insets, and in new paragraphs.
> 
> Please tell me if I can provide more info.
> g

>From your file:

> .11  0.86 0.16 16862068 0.00 0.00  
> __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator  __gnu_norm::vector std::allocator

Re: Slow motion while editing

[Guillaume Pothier]

Sorry, I forgot that flag when I compiled with profiling enabled...
I'm compiling with both now, I'll report soon.
g

On 7/20/07, Peter Kümmel <[EMAIL PROTECTED]> wrote:

Guillaume Pothier wrote:
> Here are the profiling results:
> http://www.dcc.uchile.cl/~gpothier/gprof.out
> This was using the document I already sent, typing random stuff within
> floats, in paragraphs containing math insets, and in new paragraphs.
>
> Please tell me if I can provide more info.
> g

From your file:

> .11  0.86 0.16 16862068 0.00 0.00  
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator

Re: Slow motion while editing

[Guillaume Pothier]

Hi, so I compiled lyx with profiling enabled and without debug info,
and I updated the gprof.out (same URL:
http://www.dcc.uchile.cl/~gpothier/gprof.out)
g

On 7/20/07, Peter Kümmel <[EMAIL PROTECTED]> wrote:

Guillaume Pothier wrote:
> Here are the profiling results:
> http://www.dcc.uchile.cl/~gpothier/gprof.out
> This was using the document I already sent, typing random stuff within
> floats, in paragraphs containing math insets, and in new paragraphs.
>
> Please tell me if I can provide more info.
> g

From your file:

> .11  0.86 0.16 16862068 0.00 0.00  
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator

Re: Slow motion while editing

[Guillaume Pothier]

I don't know if it is related but with the svn version compiled
yesterday there  is a very noticeable lag in typing. Attached is a
file that is causing problems.
This is with Ubuntu Linux 7.04, KDE 3.5.7 and Qy 4.3.0. The machine is
a 2GHz Pentium M with 1GB of RAM.
Regards,
g


On 7/12/07, Pavel Sanda [EMAIL PROTECTED] wrote:

 On Thu, 2007-07-12 at 15:01 +0200, Pavel Sanda wrote:
   This bug was supposed to be fixed, so perhaps it's time to re-open it.
   Please add your comments to the bug.
 
  please do you know the number ?
  i remember there was also some bug about positioning view to the last 
half-line of
  text after opening a file, which also happened when resizing now, but was 
not able to
  find it in bugz.

 It was sitting right in front of you in the message you were replying
 to :) In the part which you wrote yourself :P

i thought you point to some bug which address the wrong scrollbar
(i wrongly spelled it slider).

pavel



overview.lyx
Description: application/lyx

Re: Slow motion while editing

[Jürgen Spitzmüller]

Guillaume Pothier wrote:
 I don't know if it is related but with the svn version compiled
 yesterday there  is a very noticeable lag in typing. Attached is a
 file that is causing problems.
 This is with Ubuntu Linux 7.04, KDE 3.5.7 and Qy 4.3.0. The machine is
 a 2GHz Pentium M with 1GB of RAM.

Did you compile with --disable-stdlib-debug?

Jürgen

Re: Slow motion while editing

[Abdelrazak Younes]

Guillaume Pothier wrote:

I don't know if it is related but with the svn version compiled
yesterday there  is a very noticeable lag in typing. Attached is a
file that is causing problems.


I confirm the slowness with this file. But it is much better when 
Instant Preview is on. Please try to enable it and report back.


Do you know when this slowness appeared? Or was it always like that?

Abdel.

Re: Slow motion while editing

[Guillaume Pothier]

Ok, I also tried with --disable-stdlib-debug and I don't notice any difference.
(sorry my I forgot to do a reply all in my previous post, see below).
g

On 7/19/07, Guillaume Pothier [EMAIL PROTECTED] wrote:

I've not used lyx 1.5 before. But with 1.4.3 there was no such
slowness with this document (note that the document I attached does
not open with 1.4.3, however the original document from which I took
the attached content does open).
Instant preview produced no noticeable difference here. I'm now
recompiling with --disable-stdlib-debug as suggested by Jürgen, I'll
report as soon as possible.
g

On 7/19/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
 Guillaume Pothier wrote:
  I don't know if it is related but with the svn version compiled
  yesterday there  is a very noticeable lag in typing. Attached is a
  file that is causing problems.

 I confirm the slowness with this file. But it is much better when
 Instant Preview is on. Please try to enable it and report back.

 Do you know when this slowness appeared? Or was it always like that?

 Abdel.

Re: Slow motion while editing

[Abdelrazak Younes]

Guillaume Pothier wrote:
Ok, I also tried with --disable-stdlib-debug and I don't notice any 
difference.


Could you please try this patch?

Abdel.

Index: frontends/qt4/GuiApplication.cpp
===
--- frontends/qt4/GuiApplication.cpp(revision 18971)
+++ frontends/qt4/GuiApplication.cpp(working copy)
@@ -41,6 +41,7 @@
 #include QFileOpenEvent
 #include QLocale
 #include QLibraryInfo
+#include QPixmapCache
 #include QTextCodec
 #include QTimer
 #include QTranslator
@@ -137,6 +138,10 @@
LoaderQueue::setPriority(10,100);

guiApp = this;
+
+   // Set the cache to 5120 kilobytes which corresponds to screen size of
+   // 1280 by 1024 pixels with a color depth of 32 bits.
+   QPixmapCache::setCacheLimit(5120);
 }


Index: frontends/qt4/QLPainter.cpp
===
--- frontends/qt4/QLPainter.cpp (revision 18971)
+++ frontends/qt4/QLPainter.cpp (working copy)
@@ -11,8 +11,6 @@

 #include config.h

-#include QTextLayout
-
 #include QLPainter.h

 #include GuiApplication.h
@@ -28,12 +26,29 @@

 #include support/unicode.h

+#include QPixmapCache
+#include QTextLayout
+
 using std::endl;
 using std::string;

 namespace lyx {
 namespace frontend {

+namespace {
+
+QString generateStringSignature(QString const  str, Font const  f)
+{
+   QString sig = str;
+   sig.append(QChar(static_castshort(f.family(;
+   sig.append(QChar(static_castshort(f.series(;
+   sig.append(QChar(static_castshort(f.realShape(;
+   sig.append(QChar(static_castshort(f.size(;
+   return sig;
+}
+
+} // anon namespace
+
 QLPainter::QLPainter(QPaintDevice * device)
: QPainter(device), Painter()
 {
@@ -244,14 +259,12 @@
int textwidth;

if (f.realShape() != Font::SMALLCAPS_SHAPE) {
-   setQPainterPen(f.realColor());
-   if (font() != fi.font)
-   setFont(fi.font);
-   // We need to draw the text as LTR as we use our own bidi code.
-   setLayoutDirection(Qt::LeftToRight);
+   // Here we use the font width cache instead of
+   //   textwidth = fontMetrics().width(str);
+   // because the above is awfully expensive on MacOSX
+   textwidth = fi.metrics-width(s);
+
if (isDrawingEnabled()) {
-   LYXERR(Debug::PAINTING)  draw   
std::string(str.toUtf8())
- at   x  ,  y  std::endl;
// Qt4 does not display a glyph whose codepoint is the
// same as that of a soft-hyphen (0x00ad), unless it
// occurs at a line-break. As a kludge, we force Qt to
@@ -265,13 +278,43 @@
line.setPosition(QPointF(0, -line.ascent()));
adsymbol.endLayout();
line.draw(this, QPointF(x, y));
-   } else
-   drawText(x, y, str);
+   } else {
+   QPixmap pm;
+   QString key = generateStringSignature(str, f);
+   // Warning: Left bearing is in general 
negative! Only the case
+   // where left bearing is negative is of 
interest WRT the the 
+   // pixmap width and the text x-position.
+   // Only the left bearing of the first character 
is important as we
+   // always write from left to right, even for 
right-to-left languages.
+   int const lb = 
std::min(fi.metrics-lbearing(s[0]), 0);
+   int const mA = fi.metrics-maxAscent();
+   if (!QPixmapCache::find(key, pm)) {
+   // Only the right bearing of the last 
character is important as we
+   // always write from left to right, 
even for right-to-left languages.
+   int const rb = 
fi.metrics-rbearing(s[s.size()-1]);
+   int const w = textwidth + rb - lb;
+   int const mD = fi.metrics-maxDescent();
+   int const h = mA + mD;
+   pm = QPixmap(w, h);
+   pm.fill(Qt::transparent);
+   QLPainter p(pm);
+   p.setQPainterPen(f.realColor());
+   if (p.font() != fi.font)
+   p.setFont(fi.font);
+   // We need to draw the text as LTR as 
we use our own bidi code.
+  

Re: Slow motion while editing

[Abdelrazak Younes]

Abdelrazak Younes wrote:

Guillaume Pothier wrote:
Ok, I also tried with --disable-stdlib-debug and I don't notice any 
difference.


Could you please try this patch?


Just FYI, my mvc branch doesn't have the slowness so I guess the use of 
the pixmap  cache is doing a big difference.


I think that the reason for the slowness is that a single math inset in 
a paragraph triggers a full screen redraw. With my painting patch this 
doesn't make a difference but it does for trunk. To verify my theory, 
just type in a paragraph without a math inset in the test document. So 
two ways to solve this issue:

1) understand why any math inset provokes a full redraw and correct that.
2) apply my painting patch.

Abdel.

Re: Slow motion while editing

[Darren Freeman]

On Thu, 2007-07-19 at 22:27 +0200, Abdelrazak Younes wrote:
 Guillaume Pothier wrote:
  Ok, I also tried with --disable-stdlib-debug and I don't notice any 
  difference.
 
 Could you please try this patch?

I'm considering trying this very soon. As of the last couple of days,
editing my thesis is now noticeably slower!! I don't have to do anything
to cause this, unlike before where it would creep in over time.

OpenSUSE 10.2 on Athlon XP 3000+, 1GB RAM.

Have fun,
Darren

Re: Slow motion while editing

[Darren Freeman]

On Thu, 2007-07-19 at 22:27 +0200, Abdelrazak Younes wrote:
 Guillaume Pothier wrote:
  Ok, I also tried with --disable-stdlib-debug and I don't notice any 
  difference.
 
 Could you please try this patch?

No noticeable effect, on the same document both with and without the
patch, scrolling lag is around 0.5 s, and mashing the keyboard with
maybe 30 chars into an empty paragraph, gave a couple of s of catchup
time.

Have fun,
Darren

Re: Slow motion while editing

[Guillaume Pothier]

Abdel, I tried your patch and it actually makes things noticeably slower!
Regards,
g

On 7/19/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:

Guillaume Pothier wrote:
 Ok, I also tried with --disable-stdlib-debug and I don't notice any
 difference.

Could you please try this patch?

Abdel.

Re: Slow motion while editing

[Guillaume Pothier]

I don't know if it is related but with the svn version compiled
yesterday there  is a very noticeable lag in typing. Attached is a
file that is causing problems.
This is with Ubuntu Linux 7.04, KDE 3.5.7 and Qy 4.3.0. The machine is
a 2GHz Pentium M with 1GB of RAM.
Regards,
g


On 7/12/07, Pavel Sanda <[EMAIL PROTECTED]> wrote:

> On Thu, 2007-07-12 at 15:01 +0200, Pavel Sanda wrote:
> > > This bug was supposed to be fixed, so perhaps it's time to re-open it.
> > > Please add your comments to the bug.
> >
> > please do you know the number ?
> > i remember there was also some bug about positioning view to the last 
half-line of
> > text after opening a file, which also happened when resizing now, but was 
not able to
> > find it in bugz.
>
> It was sitting right in front of you in the message you were replying
> to :) In the part which you wrote yourself :P

i thought you point to some bug which address the wrong scrollbar
(i wrongly spelled it slider).

pavel



overview.lyx
Description: application/lyx

Re: Slow motion while editing

[Jürgen Spitzmüller]

Guillaume Pothier wrote:
> I don't know if it is related but with the svn version compiled
> yesterday there  is a very noticeable lag in typing. Attached is a
> file that is causing problems.
> This is with Ubuntu Linux 7.04, KDE 3.5.7 and Qy 4.3.0. The machine is
> a 2GHz Pentium M with 1GB of RAM.

Did you compile with --disable-stdlib-debug?

Jürgen

Re: Slow motion while editing

[Abdelrazak Younes]

Guillaume Pothier wrote:

I don't know if it is related but with the svn version compiled
yesterday there  is a very noticeable lag in typing. Attached is a
file that is causing problems.


I confirm the slowness with this file. But it is much better when 
Instant Preview is on. Please try to enable it and report back.


Do you know when this slowness appeared? Or was it always like that?

Abdel.

Re: Slow motion while editing

[Guillaume Pothier]

Ok, I also tried with --disable-stdlib-debug and I don't notice any difference.
(sorry my I forgot to do a reply all in my previous post, see below).
g

On 7/19/07, Guillaume Pothier <[EMAIL PROTECTED]> wrote:

I've not used lyx 1.5 before. But with 1.4.3 there was no such
slowness with this document (note that the document I attached does
not open with 1.4.3, however the original document from which I took
the attached content does open).
Instant preview produced no noticeable difference here. I'm now
recompiling with --disable-stdlib-debug as suggested by Jürgen, I'll
report as soon as possible.
g

On 7/19/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
> Guillaume Pothier wrote:
> > I don't know if it is related but with the svn version compiled
> > yesterday there  is a very noticeable lag in typing. Attached is a
> > file that is causing problems.
>
> I confirm the slowness with this file. But it is much better when
> Instant Preview is on. Please try to enable it and report back.
>
> Do you know when this slowness appeared? Or was it always like that?
>
> Abdel.
>
>

Re: Slow motion while editing

[Abdelrazak Younes]

Guillaume Pothier wrote:
Ok, I also tried with --disable-stdlib-debug and I don't notice any 
difference.


Could you please try this patch?

Abdel.

Index: frontends/qt4/GuiApplication.cpp
===
--- frontends/qt4/GuiApplication.cpp(revision 18971)
+++ frontends/qt4/GuiApplication.cpp(working copy)
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -137,6 +138,10 @@
LoaderQueue::setPriority(10,100);

guiApp = this;
+
+   // Set the cache to 5120 kilobytes which corresponds to screen size of
+   // 1280 by 1024 pixels with a color depth of 32 bits.
+   QPixmapCache::setCacheLimit(5120);
 }


Index: frontends/qt4/QLPainter.cpp
===
--- frontends/qt4/QLPainter.cpp (revision 18971)
+++ frontends/qt4/QLPainter.cpp (working copy)
@@ -11,8 +11,6 @@

 #include 

-#include 
-
 #include "QLPainter.h"

 #include "GuiApplication.h"
@@ -28,12 +26,29 @@

 #include "support/unicode.h"

+#include 
+#include 
+
 using std::endl;
 using std::string;

 namespace lyx {
 namespace frontend {

+namespace {
+
+QString generateStringSignature(QString const & str, Font const & f)
+{
+   QString sig = str;
+   sig.append(QChar(static_cast(f.family(;
+   sig.append(QChar(static_cast(f.series(;
+   sig.append(QChar(static_cast(f.realShape(;
+   sig.append(QChar(static_cast(f.size(;
+   return sig;
+}
+
+} // anon namespace
+
 QLPainter::QLPainter(QPaintDevice * device)
: QPainter(device), Painter()
 {
@@ -244,14 +259,12 @@
int textwidth;

if (f.realShape() != Font::SMALLCAPS_SHAPE) {
-   setQPainterPen(f.realColor());
-   if (font() != fi.font)
-   setFont(fi.font);
-   // We need to draw the text as LTR as we use our own bidi code.
-   setLayoutDirection(Qt::LeftToRight);
+   // Here we use the font width cache instead of
+   //   textwidth = fontMetrics().width(str);
+   // because the above is awfully expensive on MacOSX
+   textwidth = fi.metrics->width(s);
+
if (isDrawingEnabled()) {
-   LYXERR(Debug::PAINTING) << "draw " << 
std::string(str.toUtf8())
-   << " at " << x << "," << y << std::endl;
// Qt4 does not display a glyph whose codepoint is the
// same as that of a soft-hyphen (0x00ad), unless it
// occurs at a line-break. As a kludge, we force Qt to
@@ -265,13 +278,43 @@
line.setPosition(QPointF(0, -line.ascent()));
adsymbol.endLayout();
line.draw(this, QPointF(x, y));
-   } else
-   drawText(x, y, str);
+   } else {
+   QPixmap pm;
+   QString key = generateStringSignature(str, f);
+   // Warning: Left bearing is in general 
negative! Only the case
+   // where left bearing is negative is of 
interest WRT the the 
+   // pixmap width and the text x-position.
+   // Only the left bearing of the first character 
is important as we
+   // always write from left to right, even for 
right-to-left languages.
+   int const lb = 
std::min(fi.metrics->lbearing(s[0]), 0);
+   int const mA = fi.metrics->maxAscent();
+   if (!QPixmapCache::find(key, pm)) {
+   // Only the right bearing of the last 
character is important as we
+   // always write from left to right, 
even for right-to-left languages.
+   int const rb = 
fi.metrics->rbearing(s[s.size()-1]);
+   int const w = textwidth + rb - lb;
+   int const mD = fi.metrics->maxDescent();
+   int const h = mA + mD;
+   pm = QPixmap(w, h);
+   pm.fill(Qt::transparent);
+   QLPainter p();
+   p.setQPainterPen(f.realColor());
+   if (p.font() != fi.font)
+   p.setFont(fi.font);
+   // We need to draw the text as LTR as 
we use our own bidi code.
+   p.setLayoutDirection(Qt::LeftToRight);
+   

Re: Slow motion while editing

[Abdelrazak Younes]

Abdelrazak Younes wrote:

Guillaume Pothier wrote:
Ok, I also tried with --disable-stdlib-debug and I don't notice any 
difference.


Could you please try this patch?


Just FYI, my mvc branch doesn't have the slowness so I guess the use of 
the pixmap  cache is doing a big difference.


I think that the reason for the slowness is that a single math inset in 
a paragraph triggers a full screen redraw. With my painting patch this 
doesn't make a difference but it does for trunk. To verify my theory, 
just type in a paragraph without a math inset in the test document. So 
two ways to solve this issue:

1) understand why any math inset provokes a full redraw and correct that.
2) apply my painting patch.

Abdel.

Re: Slow motion while editing

[Darren Freeman]

On Thu, 2007-07-19 at 22:27 +0200, Abdelrazak Younes wrote:
> Guillaume Pothier wrote:
> > Ok, I also tried with --disable-stdlib-debug and I don't notice any 
> > difference.
> 
> Could you please try this patch?

I'm considering trying this very soon. As of the last couple of days,
editing my thesis is now noticeably slower!! I don't have to do anything
to cause this, unlike before where it would creep in over time.

OpenSUSE 10.2 on Athlon XP 3000+, 1GB RAM.

Have fun,
Darren

Re: Slow motion while editing

[Darren Freeman]

On Thu, 2007-07-19 at 22:27 +0200, Abdelrazak Younes wrote:
> Guillaume Pothier wrote:
> > Ok, I also tried with --disable-stdlib-debug and I don't notice any 
> > difference.
> 
> Could you please try this patch?

No noticeable effect, on the same document both with and without the
patch, scrolling lag is around 0.5 s, and mashing the keyboard with
maybe 30 chars into an empty paragraph, gave a couple of s of catchup
time.

Have fun,
Darren

Re: Slow motion while editing

[Guillaume Pothier]

Abdel, I tried your patch and it actually makes things noticeably slower!
Regards,
g

On 7/19/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

Guillaume Pothier wrote:
> Ok, I also tried with --disable-stdlib-debug and I don't notice any
> difference.

Could you please try this patch?

Abdel.

Re: Slow motion while editing

[Darren Freeman]

On Wed, 2007-07-11 at 14:06 +0200, Pavel Sanda wrote:
 Hello,
 
 I haven't closely followed the debates concerning the cursor motion speed
 and don't know what is the current status (some patches pending?) but
 as I started work 1.5rc2 the typing speed is slow and to wait when 
 moving with cursor in text is very painful (this applies to situation
 when i start new document, havent experimentated more up to this moment).
 
 But what I accidentally found is, that the whole problem simply disappears 
 in the moment I copy and paste some text. Is this known ?

Does it resemble this?

http://bugzilla.lyx.org/show_bug.cgi?id=3700

Try resizing the window and then resizing it back. If that clears it as
well it's the same problem.

Have fun,
Darren

Re: Slow motion while editing

[Darren Freeman]

On Wed, 2007-07-11 at 09:29 -0500, Bo Peng wrote:
  Must be an X11 selection problem cause I can't reproduce under Windows.
 
 The report lacks some details but I can not reproduce anything here
 either. (Linux). I have a fast machine though.

If it's the problem I reported (see a recent reply by me), then I think
it's still happening in SVN. I am running OpenSUSE 10.2 on an Athlon XP
3000+.

I think I might have learnt to tune it out of my mind but it's
frustrating as hell.

Have fun,
Darren

Re: Slow motion while editing

[Pavel Sanda]

 Must be an X11 selection problem cause I can't reproduce under Windows.
 
 The report lacks some details but I can not reproduce anything here

which details you want to provide ?

 either. (Linux). I have a fast machine though.

here pentium-4 3GHz.
dont know whether gkrellm is reliable enough but this slowness
probably has nothing to do with computation demands, cpu-usage
remains very very low - it seems like there is some lock or sleep
involved.

pavel

Re: Slow motion while editing

[Abdelrazak Younes]

Pavel Sanda wrote:

Must be an X11 selection problem cause I can't reproduce under Windows.

The report lacks some details but I can not reproduce anything here


which details you want to provide ?


either. (Linux). I have a fast machine though.


here pentium-4 3GHz.
dont know whether gkrellm is reliable enough but this slowness
probably has nothing to do with computation demands, cpu-usage
remains very very low - it seems like there is some lock or sleep
involved.


Which sytem is that? If it is KDE or GNOME based, maybe there's some 
global Clipboard or X11 Selection issue... could you please try to 
launch a bare X11 session with a minimalist window manager (i.e. without 
KDE nor Gnome) and report back?


Abdel.

Re: Slow motion while editing

[Pavel Sanda]

  But what I accidentally found is, that the whole problem simply disappears 
  in the moment I copy and paste some text. Is this known ?
 

 Does it resemble this?

does copying text by Ctrl+C helps for you ?

 
 http://bugzilla.lyx.org/show_bug.cgi?id=3700
 
 Try resizing the window and then resizing it back. If that clears it as
 well it's the same problem.

i was trying to resize the window in many ways but havent succeeded, the
problem remains. seems to be different issue.

moreover that while i was playing few minutes only with resizing i came to
new displaying problem which resembles 
http://bugzilla.lyx.org/show_bug.cgi?id=3231
sometimes only paragraph of cursor is visible - but in this case
even the current paragraph was not visible and you have to move cursor to make
it appear. it does not happen always but usually when you resize the window
to some very small area - say one word width, three lines height and then
you resize it back (or maximize). more - the slider on the right side is often 
in
a position, which cannot be reached again and its size is different after you
move with cursor and screen gets repainted.

pavel

Re: Slow motion while editing

[Pavel Sanda]

 Which sytem is that? If it is KDE or GNOME based, maybe there's some 
 global Clipboard or X11 Selection issue... could you please try to 
 launch a bare X11 session with a minimalist window manager (i.e. without 
 KDE nor Gnome) and report back?

i use only enlightenment 0.16. is it minimalistic enough ?

pavel

Re: Slow motion while editing

[Abdelrazak Younes]

Pavel Sanda wrote:
Which sytem is that? If it is KDE or GNOME based, maybe there's some 
global Clipboard or X11 Selection issue... could you please try to 
launch a bare X11 session with a minimalist window manager (i.e. without 
KDE nor Gnome) and report back?


i use only enlightenment 0.16. is it minimalistic enough ?


I don't know... enlightenment is a kind of desktop too, isn't it? Maybe 
there's some bad interactions with the clipboard... I've been using 
Windows for the last 6 years so I am probably talking nonsense here.


Abdel.

Re: Slow motion while editing

[Pavel Sanda]

  but I cannot reproduce it.
 
 can you try this ?
 1. launch lyx
 2. new file + some typing + mark text + copy
 3. launch new instance (let the old one running) + new + type some text + try 
 motion

just one more addition: - the slow motion is only in one of those two windows - 
the
other one, than the one where Ctrl+C was done.

i can even play with switching which window will be the slow one by Ctrl+C.

pavel

Re: Slow motion while editing

[Darren Freeman]

On Thu, 2007-07-12 at 12:18 +0200, Pavel Sanda wrote:
   But what I accidentally found is, that the whole problem simply 
   disappears 
   in the moment I copy and paste some text. Is this known ?
  
 
  Does it resemble this?
 
 does copying text by Ctrl+C helps for you ?

Not that I know of.

 i was trying to resize the window in many ways but havent succeeded, the
 problem remains. seems to be different issue.

Then maybe it's time to file a bug report.

 moreover that while i was playing few minutes only with resizing i came to
 new displaying problem which resembles 
 http://bugzilla.lyx.org/show_bug.cgi?id=3231
 sometimes only paragraph of cursor is visible - but in this case
 even the current paragraph was not visible and you have to move cursor to make

That's a common part of the bug. The current paragraph sometimes isn't
visible either.

 it appear. it does not happen always but usually when you resize the window
 to some very small area - say one word width, three lines height and then
 you resize it back (or maximize). more - the slider on the right side is 
 often in
 a position, which cannot be reached again and its size is different after you
 move with cursor and screen gets repainted.

This bug was supposed to be fixed, so perhaps it's time to re-open it.
Please add your comments to the bug.

Have fun,
Darren

Re: Slow motion while editing

[Abdelrazak Younes]

Pavel Sanda wrote:

but I cannot reproduce it.

can you try this ?
1. launch lyx
2. new file + some typing + mark text + copy
3. launch new instance (let the old one running) + new + type some text + try 
motion


just one more addition: - the slow motion is only in one of those two windows - 
the
other one, than the one where Ctrl+C was done.

i can even play with switching which window will be the slow one by Ctrl+C.


By the way, you know that LyX now can do multiple views, don't you? Can 
you reproduce the slow motion with two windows of the same instance?


Abdel.

Re: Slow motion while editing

[Pavel Sanda]

 By the way, you know that LyX now can do multiple views, don't you? Can 
 you reproduce the slow motion with two windows of the same instance?

no, i can not reproduce it on the same instance.
pavel

Re: Slow motion while editing

[Abdelrazak Younes]

Pavel Sanda wrote:
By the way, you know that LyX now can do multiple views, don't you? Can 
you reproduce the slow motion with two windows of the same instance?


no, i can not reproduce it on the same instance.


At last a good news :-)

Maybe it is a problem of Qt then. I don't know how Qt handle the 
clipboard but as two instance of LyX uses the same instance of Qt 
(unless you compiled statically) there might be some interaction problem 
between the two instances. This is just wild guessing...


Anyway, at least you have a work-around for your problem now ;-)

Abdel.

Re: Slow motion while editing

[Pavel Sanda]

 By the way, you know that LyX now can do multiple views, don't you? Can 
 you reproduce the slow motion with two windows of the same instance?
 
 Abdel.

btw abdel, if you want i can provide you ssh account on the machine to
fathom this.

pavel

Re: Slow motion while editing

[Pavel Sanda]

 Pavel Sanda wrote:
 Which sytem is that? If it is KDE or GNOME based, maybe there's some 
 global Clipboard or X11 Selection issue... could you please try to 
 launch a bare X11 session with a minimalist window manager (i.e. without 
 KDE nor Gnome) and report back?
 
 i use only enlightenment 0.16. is it minimalistic enough ?
 
 I don't know... enlightenment is a kind of desktop too, isn't it? Maybe 
 there's some bad interactions with the clipboard... I've been using 
 Windows for the last 6 years so I am probably talking nonsense here.

ok, i run X without any WM or desktop and came to this - 
it _seems_ (its difficult to test extensively as you cant switch between
windows without WM :) that motion itself is much better, but what remains
is extremely slow motion when selecting text with shift+arrows - previously
i considered that this slowness is just consequence of the motion itself
but now it seems to be issue itself.

pavel

Re: Slow motion while editing

[Abdelrazak Younes]

Pavel Sanda wrote:
By the way, you know that LyX now can do multiple views, don't you? Can 
you reproduce the slow motion with two windows of the same instance?


Abdel.


btw abdel, if you want i can provide you ssh account on the machine to
fathom this.


I would need an X11 server to do that and more time to setup everything 
and debug it than I can really afford. So, thanks but no, I think your 
problem is not worth it, no offense ;-)


Abdel.

Re: Slow motion while editing

[Abdelrazak Younes]

Pavel Sanda wrote:

Pavel Sanda wrote:
Which sytem is that? If it is KDE or GNOME based, maybe there's some 
global Clipboard or X11 Selection issue... could you please try to 
launch a bare X11 session with a minimalist window manager (i.e. without 
KDE nor Gnome) and report back?

i use only enlightenment 0.16. is it minimalistic enough ?
I don't know... enlightenment is a kind of desktop too, isn't it? Maybe 
there's some bad interactions with the clipboard... I've been using 
Windows for the last 6 years so I am probably talking nonsense here.


ok, i run X without any WM or desktop and came to this - 
it _seems_ (its difficult to test extensively as you cant switch between

windows without WM :) that motion itself is much better, but what remains
is extremely slow motion when selecting text with shift+arrows


Even with a single instance? Following our recent cleanup in this area, 
there should not be any buffering done at selection time, only at 
clearing selection time. Still, LyX request the X11 selection handle 
upon each selection operation (such as selecting text with 
shift+arrows); requesting the X11 selection is not supposed to be costly 
at all so I am tending to think that maybe you X server is buggy. You 
could try to upgrade it and see how it goes.


 - previously

i considered that this slowness is just consequence of the motion itself
but now it seems to be issue itself.


Looks like yes.

Abdel.

Re: Slow motion while editing

[Pavel Sanda]

 ok, i run X without any WM or desktop and came to this - 
 it _seems_ (its difficult to test extensively as you cant switch between
 windows without WM :) that motion itself is much better, but what remains
 is extremely slow motion when selecting text with shift+arrows
 
 Even with a single instance? 

no. i run first instance, copy text. then the second - and in this second
slowness happens. i just cant switch to the previous one to make more 
experiments.
pavel

Re: Slow motion while editing

[Martin Vermeer]

On Thu, 12 Jul 2007 14:11:33 +0200
Pavel Sanda [EMAIL PROTECTED] wrote:

  Pavel Sanda wrote:
  Which sytem is that? If it is KDE or GNOME based, maybe there's some 
  global Clipboard or X11 Selection issue... could you please try to 
  launch a bare X11 session with a minimalist window manager (i.e. without 
  KDE nor Gnome) and report back?
  
  i use only enlightenment 0.16. is it minimalistic enough ?
  
  I don't know... enlightenment is a kind of desktop too, isn't it? Maybe 
  there's some bad interactions with the clipboard... I've been using 
  Windows for the last 6 years so I am probably talking nonsense here.
 
 ok, i run X without any WM or desktop and came to this - 
 it _seems_ (its difficult to test extensively as you cant switch between
 windows without WM :) that motion itself is much better, but what remains
 is extremely slow motion when selecting text with shift+arrows - previously
 i considered that this slowness is just consequence of the motion itself
 but now it seems to be issue itself.

This rings a bell... some of the SinglePar optimizations are not used when
selecting. 

(Is my old work on this stuff still in the code? If not, ignore me.)

- Martin

Re: Slow motion while editing

[Pavel Sanda]

  it appear. it does not happen always but usually when you resize the window
  to some very small area - say one word width, three lines height and then
  you resize it back (or maximize). more - the slider on the right side is 
  often in
  a position, which cannot be reached again and its size is different after 
  you
  move with cursor and screen gets repainted.
 
 This bug was supposed to be fixed, so perhaps it's time to re-open it.
 Please add your comments to the bug.

please do you know the number ?
i remember there was also some bug about positioning view to the last half-line 
of
text after opening a file, which also happened when resizing now, but was not 
able to
find it in bugz.

pavel

Re: Slow motion while editing

[Darren Freeman]

On Thu, 2007-07-12 at 15:01 +0200, Pavel Sanda wrote:
  This bug was supposed to be fixed, so perhaps it's time to re-open it.
  Please add your comments to the bug.
 
 please do you know the number ?
 i remember there was also some bug about positioning view to the last 
 half-line of
 text after opening a file, which also happened when resizing now, but was not 
 able to
 find it in bugz.

It was sitting right in front of you in the message you were replying
to :) In the part which you wrote yourself :P

 moreover that while i was playing few minutes only with resizing i
came to
 new displaying problem which resembles
http://bugzilla.lyx.org/show_bug.cgi?id=3231
 sometimes only paragraph of cursor is visible - but in this case
 even the current paragraph was not visible and you have to move cursor
to make

Have fun,
Darren

Re: Slow motion while editing

[Pavel Sanda]

 On Thu, 2007-07-12 at 15:01 +0200, Pavel Sanda wrote:
   This bug was supposed to be fixed, so perhaps it's time to re-open it.
   Please add your comments to the bug.
  
  please do you know the number ?
  i remember there was also some bug about positioning view to the last 
  half-line of
  text after opening a file, which also happened when resizing now, but was 
  not able to
  find it in bugz.
 
 It was sitting right in front of you in the message you were replying
 to :) In the part which you wrote yourself :P

i thought you point to some bug which address the wrong scrollbar
(i wrongly spelled it slider).

pavel

Re: Slow motion while editing

[Darren Freeman]

On Wed, 2007-07-11 at 14:06 +0200, Pavel Sanda wrote:
> Hello,
> 
> I haven't closely followed the debates concerning the cursor motion speed
> and don't know what is the current status (some patches pending?) but
> as I started work 1.5rc2 the typing speed is slow and to wait when 
> moving with cursor in text is very painful (this applies to situation
> when i start new document, havent experimentated more up to this moment).
> 
> But what I accidentally found is, that the whole problem simply disappears 
> in the moment I copy and paste some text. Is this known ?

Does it resemble this?

http://bugzilla.lyx.org/show_bug.cgi?id=3700

Try resizing the window and then resizing it back. If that clears it as
well it's the same problem.

Have fun,
Darren

Re: Slow motion while editing

[Darren Freeman]

On Wed, 2007-07-11 at 09:29 -0500, Bo Peng wrote:
> > Must be an X11 selection problem cause I can't reproduce under Windows.
> 
> The report lacks some details but I can not reproduce anything here
> either. (Linux). I have a fast machine though.

If it's the problem I reported (see a recent reply by me), then I think
it's still happening in SVN. I am running OpenSUSE 10.2 on an Athlon XP
3000+.

I think I might have learnt to tune it out of my mind but it's
frustrating as hell.

Have fun,
Darren

Re: Slow motion while editing

[Pavel Sanda]

> >Must be an X11 selection problem cause I can't reproduce under Windows.
> 
> The report lacks some details but I can not reproduce anything here

which details you want to provide ?

> either. (Linux). I have a fast machine though.

here pentium-4 3GHz.
dont know whether gkrellm is reliable enough but this slowness
probably has nothing to do with computation demands, cpu-usage
remains very very low - it seems like there is some lock or sleep
involved.

pavel

Re: Slow motion while editing

[Abdelrazak Younes]

Pavel Sanda wrote:

Must be an X11 selection problem cause I can't reproduce under Windows.

The report lacks some details but I can not reproduce anything here


which details you want to provide ?


either. (Linux). I have a fast machine though.


here pentium-4 3GHz.
dont know whether gkrellm is reliable enough but this slowness
probably has nothing to do with computation demands, cpu-usage
remains very very low - it seems like there is some lock or sleep
involved.


Which sytem is that? If it is KDE or GNOME based, maybe there's some 
global Clipboard or X11 Selection issue... could you please try to 
launch a bare X11 session with a minimalist window manager (i.e. without 
KDE nor Gnome) and report back?


Abdel.

Re: Slow motion while editing

[Pavel Sanda]

> > But what I accidentally found is, that the whole problem simply disappears 
> > in the moment I copy and paste some text. Is this known ?
> 

> Does it resemble this?

does copying text by Ctrl+C helps for you ?

> 
> http://bugzilla.lyx.org/show_bug.cgi?id=3700
> 
> Try resizing the window and then resizing it back. If that clears it as
> well it's the same problem.

i was trying to resize the window in many ways but havent succeeded, the
problem remains. seems to be different issue.

moreover that while i was playing few minutes only with resizing i came to
new displaying problem which resembles 
http://bugzilla.lyx.org/show_bug.cgi?id=3231
"sometimes only paragraph of cursor is visible" - but in this case
even the current paragraph was not visible and you have to move cursor to make
it appear. it does not happen always but usually when you resize the window
to some very small area - say one word width, three lines height and then
you resize it back (or maximize). more - the slider on the right side is often 
in
a position, which cannot be reached again and its size is different after you
move with cursor and screen gets repainted.

pavel

Re: Slow motion while editing

[Pavel Sanda]

> Which sytem is that? If it is KDE or GNOME based, maybe there's some 
> global Clipboard or X11 Selection issue... could you please try to 
> launch a bare X11 session with a minimalist window manager (i.e. without 
> KDE nor Gnome) and report back?

i use only enlightenment 0.16. is it minimalistic enough ?

pavel

Re: Slow motion while editing

[Abdelrazak Younes]

Pavel Sanda wrote:
Which sytem is that? If it is KDE or GNOME based, maybe there's some 
global Clipboard or X11 Selection issue... could you please try to 
launch a bare X11 session with a minimalist window manager (i.e. without 
KDE nor Gnome) and report back?


i use only enlightenment 0.16. is it minimalistic enough ?


I don't know... enlightenment is a kind of desktop too, isn't it? Maybe 
there's some bad interactions with the clipboard... I've been using 
Windows for the last 6 years so I am probably talking nonsense here.


Abdel.