Re: Profiling results of scrolling through the Users Guide

[Peter Kümmel]

On 10.06.2011 09:41, Stephan Witt wrote:


But metrics computation looks innocent in the profiles.



Attached the output of gprof on Linux and Mac.
On the Mac there is no timing, but on both systems
we have the number of function calls, so it gives
at least an idea which function should be reviewed.

Peter

gprof flat profile:

MAC:

  %   cumulative   self  self total   
 time   seconds   secondscalls  ms/call  ms/call  name
  0.0   0.00 0.00 11815905 0.00 0.00  
__ZNK3lyx16ParagraphMetrics11singleWidthElRKNS_4FontE [44627]
  0.0   0.00 0.00  8105248 0.00 0.00  
__ZN3lyx10RowPainter9paintTextEv cycle 10 [44628]
  0.0   0.00 0.00  7989701 0.00 0.00  
__ZNK3lyx11TextMetrics11displayFontEll [44629]
  0.0   0.00 0.00  6187215 0.00 0.00  
__ZNK3lyx11TextMetrics13rowBreakPointEill [44630]
  0.0   0.00 0.00  5529744 0.00 0.00  
__ZN3lyx6Buffer4Impl12updateMacrosERNS_11DocIteratorES3_ [44631]
  0.0   0.00 0.00  3797311 0.00 0.00  
__ZN3lyx10RowPainter10paintCharsERlRKNS_8FontInfoEbb [44632]
  0.0   0.00 0.00  3575789 0.00 0.00  
__ZN3lyx8frontend10GuiPainter4textEiiRKSbIwSt11char_traitsIwESaIwEERKNS_8FontInfoE
 [44633]
  0.0   0.00 0.00  2712365 0.00 0.00  
__ZN3lyx10RowPainter12paintFromPosERlb [44634]
  0.0   0.00 0.00  2670167 0.00 0.00  
__ZNK3lyx11TextMetrics8rowWidthEilll [44635]
  0.0   0.00 0.00  2627345 0.00 0.00  
__ZN3lyx8frontend10FontLoader7metricsERKNS_8FontInfoE [44636]
  0.0   0.00 0.00  2221481 0.00 0.00  
__ZN3lyx4Bidi13computeTablesERKNS_9ParagraphERKNS_6BufferERKNS_3RowE [44637]
  0.0   0.00 0.00  2127497 0.00 0.00  
__ZNK3lyx11TextMetrics10leftMarginEill [44638]
  0.0   0.00 0.00  1877270 0.00 0.00  
__ZNK3lyx11TextMetrics17computeRowMetricsElRNS_3RowEi [44639]
  0.0   0.00 0.00  1704868 0.00 0.00  
__ZNK3lyx4Text10isMainTextEv [44640]
  0.0   0.00 0.00  1538904 0.00 0.00  
__ZNK3lyx11DocIterator9paragraphEv [44641]
  0.0   0.00 0.00  1523285 0.00 0.00  
__ZNK3lyx9Paragraph15getFontSettingsERKNS_12BufferParamsEl [44642]
  0.0   0.00 0.00  1305402 0.00 0.00  
__ZN3lyx10RowPainter16paintForeignMarkEdPKNS_8LanguageEi [44643]
  0.0   0.00 0.00  1139412 0.00 0.00  
__ZNK3lyx9Paragraph15isWordSeparatorEl [44644]
  0.0   0.00 0.00  1032866 0.00 0.00  
__ZNK3lyx12BufferParams7getFontEv [44645]
  0.0   0.00 0.00  1002021 0.00 0.00  
__ZNK3lyx12InsetTabular7getTextEi [44646]
  0.0   0.00 0.00   959852 0.00 0.00  
__ZN3lyx11DocIterator12forwardInsetEv [44647]
  
  
Linux:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls  ms/call  ms/call  name
  7.41  0.08 0.08  3118683 0.00 0.00  
lyx::frontend::GuiFontMetrics::width(wchar_t) const
  6.48  0.15 0.07  154 0.45 1.14  
lyx::Buffer::Impl::updateMacros(lyx::DocIterator, lyx::DocIterator)
  4.63  0.20 0.05  3579934 0.00 0.00  lyx::frontend::(anonymous 
namespace)::fontinfo(lyx::FontInfo const)
  4.63  0.25 0.05   628850 0.00 0.00  
lyx::Paragraph::insetList() const
  4.17  0.30 0.05   740638 0.00 0.00  
lyx::TextMetrics::displayFont(long, long) const
  3.70  0.34 0.04   508983 0.00 0.00  
lyx::RowPainter::paintChars(long, lyx::FontInfo const, bool, bool)
  2.78  0.37 0.03   596815 0.00 0.00  
lyx::Paragraph::fontSpan(long) const
  2.78  0.40 0.03   244603 0.00 0.00  
lyx::DocIterator::lastpit() const
  2.78  0.43 0.0319562 0.00 0.00  
std::_Rb_treestd::string, std::pairstd::string const, 
std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t  
, std::_Select1ststd::pairstd::string const, std::basic_stringwchar_t, 
std::char_traitswchar_t, std::allocatorwchar_t   , 
std::lessstd::string, std::allocatorstd::pairstd::string const, 
std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t  
  ::find(std::string const)
  2.78  0.46 0.0310660 0.00 0.03  
lyx::RowPainter::paintText()
  2.31  0.48 0.03   801567 0.00 0.00  lyx::Text::isMainText() 
const
  1.85  0.50 0.02  2319515 0.00 0.00  
lyx::ParagraphMetrics::singleWidth(long, lyx::Font const) const
  1.85  0.52 0.02  1407038 0.00 0.00  
lyx::Paragraph::getFontSettings(lyx::BufferParams const, long) const
  1.85  0.54 0.02   515770 0.00 0.00  
lyx::frontend::GuiPainter::text(int, int, std::basic_stringwchar_t, 
std::char_traitswchar_t, std::allocatorwchar_t  const, lyx::FontInfo 
const)
  1.85  0.56 0.02   311312 0.00 0.00  
lyx::Tabular::cellInset(unsigned long) const
  1.85

Re: Profiling results of scrolling through the Users Guide

[Peter Kümmel]

On 10.06.2011 09:41, Stephan Witt wrote:


But metrics computation looks innocent in the profiles.



Attached the output of gprof on Linux and Mac.
On the Mac there is no timing, but on both systems
we have the number of function calls, so it gives
at least an idea which function should be reviewed.

Peter

gprof flat profile:

MAC:

  %   cumulative   self  self total   
 time   seconds   secondscalls  ms/call  ms/call  name
  0.0   0.00 0.00 11815905 0.00 0.00  
__ZNK3lyx16ParagraphMetrics11singleWidthElRKNS_4FontE [44627]
  0.0   0.00 0.00  8105248 0.00 0.00  
__ZN3lyx10RowPainter9paintTextEv  [44628]
  0.0   0.00 0.00  7989701 0.00 0.00  
__ZNK3lyx11TextMetrics11displayFontEll [44629]
  0.0   0.00 0.00  6187215 0.00 0.00  
__ZNK3lyx11TextMetrics13rowBreakPointEill [44630]
  0.0   0.00 0.00  5529744 0.00 0.00  
__ZN3lyx6Buffer4Impl12updateMacrosERNS_11DocIteratorES3_ [44631]
  0.0   0.00 0.00  3797311 0.00 0.00  
__ZN3lyx10RowPainter10paintCharsERlRKNS_8FontInfoEbb [44632]
  0.0   0.00 0.00  3575789 0.00 0.00  
__ZN3lyx8frontend10GuiPainter4textEiiRKSbIwSt11char_traitsIwESaIwEERKNS_8FontInfoE
 [44633]
  0.0   0.00 0.00  2712365 0.00 0.00  
__ZN3lyx10RowPainter12paintFromPosERlb [44634]
  0.0   0.00 0.00  2670167 0.00 0.00  
__ZNK3lyx11TextMetrics8rowWidthEilll [44635]
  0.0   0.00 0.00  2627345 0.00 0.00  
__ZN3lyx8frontend10FontLoader7metricsERKNS_8FontInfoE [44636]
  0.0   0.00 0.00  2221481 0.00 0.00  
__ZN3lyx4Bidi13computeTablesERKNS_9ParagraphERKNS_6BufferERKNS_3RowE [44637]
  0.0   0.00 0.00  2127497 0.00 0.00  
__ZNK3lyx11TextMetrics10leftMarginEill [44638]
  0.0   0.00 0.00  1877270 0.00 0.00  
__ZNK3lyx11TextMetrics17computeRowMetricsElRNS_3RowEi [44639]
  0.0   0.00 0.00  1704868 0.00 0.00  
__ZNK3lyx4Text10isMainTextEv [44640]
  0.0   0.00 0.00  1538904 0.00 0.00  
__ZNK3lyx11DocIterator9paragraphEv [44641]
  0.0   0.00 0.00  1523285 0.00 0.00  
__ZNK3lyx9Paragraph15getFontSettingsERKNS_12BufferParamsEl [44642]
  0.0   0.00 0.00  1305402 0.00 0.00  
__ZN3lyx10RowPainter16paintForeignMarkEdPKNS_8LanguageEi [44643]
  0.0   0.00 0.00  1139412 0.00 0.00  
__ZNK3lyx9Paragraph15isWordSeparatorEl [44644]
  0.0   0.00 0.00  1032866 0.00 0.00  
__ZNK3lyx12BufferParams7getFontEv [44645]
  0.0   0.00 0.00  1002021 0.00 0.00  
__ZNK3lyx12InsetTabular7getTextEi [44646]
  0.0   0.00 0.00   959852 0.00 0.00  
__ZN3lyx11DocIterator12forwardInsetEv [44647]
  
  
Linux:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls  ms/call  ms/call  name
  7.41  0.08 0.08  3118683 0.00 0.00  
lyx::frontend::GuiFontMetrics::width(wchar_t) const
  6.48  0.15 0.07  154 0.45 1.14  
lyx::Buffer::Impl::updateMacros(lyx::DocIterator&, lyx::DocIterator&)
  4.63  0.20 0.05  3579934 0.00 0.00  lyx::frontend::(anonymous 
namespace)::fontinfo(lyx::FontInfo const&)
  4.63  0.25 0.05   628850 0.00 0.00  
lyx::Paragraph::insetList() const
  4.17  0.30 0.05   740638 0.00 0.00  
lyx::TextMetrics::displayFont(long, long) const
  3.70  0.34 0.04   508983 0.00 0.00  
lyx::RowPainter::paintChars(long&, lyx::FontInfo const&, bool, bool)
  2.78  0.37 0.03   596815 0.00 0.00  
lyx::Paragraph::fontSpan(long) const
  2.78  0.40 0.03   244603 0.00 0.00  
lyx::DocIterator::lastpit() const
  2.78  0.43 0.0319562 0.00 0.00  
std::_Rb_tree 
>, std::_Select1st > >, 
std::less, std::allocator 
> > >::find(std::string const&)
  2.78  0.46 0.0310660 0.00 0.03  
lyx::RowPainter::paintText()
  2.31  0.48 0.03   801567 0.00 0.00  lyx::Text::isMainText() 
const
  1.85  0.50 0.02  2319515 0.00 0.00  
lyx::ParagraphMetrics::singleWidth(long, lyx::Font const&) const
  1.85  0.52 0.02  1407038 0.00 0.00  
lyx::Paragraph::getFontSettings(lyx::BufferParams const&, long) const
  1.85  0.54 0.02   515770 0.00 0.00  
lyx::frontend::GuiPainter::text(int, int, std::basic_string const&, lyx::FontInfo 
const&)
  1.85  0.56 0.02   311312 0.00 0.00  
lyx::Tabular::cellInset(unsigned long) const
  1.85  0.58 0.0213987 0.00 0.01  
lyx::TextMetrics::rowBreakPoint(int, long, long) const
  1.85  0.60 0.0211457 0.00 0.00  
lyx::Bidi::computeTables(lyx::Paragraph const&, lyx::Buffer const&, lyx::Row 

Re: Profiling results of scrolling through the Users Guide

[Stephan Witt]

Am 10.06.2011 um 03:00 schrieb Richard Heck:

 On 06/09/2011 04:03 PM, Stephan Witt wrote:
 Am 09.06.2011 um 20:21 schrieb Peter Kümmel:
 
 On 09.06.2011 08:12, Stephan Witt wrote:
 To investigate the recently mentioned scrolling problems I did some 
 profiling on my machine.
 See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html
 
 Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk)
 but it's interesting too. To scroll with Page-Down through the Users Guide 
 completely
 I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there 
 are images,
 tables and math. I did this twice. The first time with drawing of text 
 fragments and
 the 2nd time with single character drawing.
 
 While doing this I collected the time profile with Shark, the profiler 
 tool of Xcode.
 
 The most interesting observation I've made is: most of the time LyX is 
 busy with other
 things - not with screen drawing. The scroll operation cost is 5% for the 
 first and 15%
 for the second variant of drawing.
 The other things are thread and socket management and QProcess's doing.
 
 Stephan
 
 OK, it is Enrico's job to ask for, but could rerun the test with 
 USE_QPROCESS undefined?
 
 Peter
 There is no difference in response time. Scroll speed is the same.
 The numbers are changing a little bit, perhaps it's a little bit faster.
 But it's far from a valuable performance gain.
 
 I suspect, but hardly know, that in this case QProcess is simply being used 
 to launch things like graphics conversions, and it would be shocking if using 
 it instead of whatever we use instead was the issue here.

I'm lost with this too. I suspect, QProcess is doing some work every time, e. 
g. querying for lost children.
The conversion of graphics shouldn't happen, all of them are cached already. Or 
am I missing something?
In fact, I'm using the Users Guide for my tests regularly.
 
 I suspect that the issue relates more to what we have to do every time the 
 screen moves, and I believe we do that---e.g., recalculate metrics prior to 
 redrawing the screen, which may involve a buffer update, etc, etc---each time 
 new material appears on the screen, which could be every 0.1 seconds or so if 
 you are scrolling quickly, or holding down PageDn. A shot in the dark: Could 
 one interrupt these processes when a new scroll event happens? Why finish 
 calculating the metrics when we know they are about to be irrelevant?

But metrics computation looks innocent in the profiles.

Am 10.06.2011 um 01:42 schrieb Pavel Sanda:

 Stephan Witt wrote:
 To investigate the recently mentioned scrolling problems I did some 
 profiling on my machine.
 See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html
 
 i'm afraid we need exactly the setup where X is the main consumer.

Agreed. I think the combination of this Xserver and current LyX behaves 
sub-optimal.
On my Mac and my Linux running in VMware I don't have this 

 
 Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk) 
 but it's interesting too. To scroll with Page-Down through the Users Guide 
 completely 
 I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there 
 are images,
 tables and math. I did this twice. The first time with drawing of text 
 fragments and
 the 2nd time with single character drawing. 
 
 While doing this I collected the time profile with Shark, the profiler tool 
 of Xcode.
 
 The most interesting observation I've made is: most of the time LyX is busy 
 with other
 things - not with screen drawing. The scroll operation cost is 5% for the 
 first and 15%
 for the second variant of drawing.
 The other things are thread and socket management and QProcess's doing.
 
 dont know shark but i guess this is misinterpretation. socket and thread 
 managment 
 look as main consumers just because the percentage is cumulative, no? (ie all 
 the computation
 which happens under lyx::start will be automatically added to its callers - 
 socketthread)

Yes, maybe. There is an option in Shark to add system calls costs and code 
without debug info to there callers.

When using it I cannot see QProcess and socket ops anymore.
I guess it's cumulated in the 23.8% for lyx::frontend::GuiApplication::exec() 
then.

Stephan

The statistics excerpt:

Self+Children
0.0%100.0%  main
0.0%99.9%lyx::LyX::exec(int, char**)
23.8%   94.8% lyx::frontend::GuiApplication::exec()
0.7%62.2%  lyx::frontend::GuiApplication::notify(QObject*, QEvent*)
0.0%51.8%   
lyx::frontend::GuiProgressView::qt_metacall(QMetaObject::Call, int, void**)
0.9%51.8%lyx::frontend::GuiProgressView::appendLyXErrText(QString 
const)
1.9%50.9% lyx::frontend::GuiApplication::notify(QObject*, QEvent*)
0.0%28.4%  lyx::frontend::GuiWorkArea::event(QEvent*)
0.0%28.4%   lyx::frontend::GuiWorkArea::keyPressEvent(QKeyEvent*)
0.0%28.4%

Re: Profiling results of scrolling through the Users Guide

[Pavel Sanda]

Stephan Witt wrote:
  dont know shark but i guess this is misinterpretation. socket and thread 
  managment 
  look as main consumers just because the percentage is cumulative, no? (ie 
  all the computation
  which happens under lyx::start will be automatically added to its callers - 
  socketthread)
 
 Yes, maybe. There is an option in Shark to add system calls costs and code 
 without debug info to there callers.

i think something can be guessed when looking on two stats - one for self one 
for cumulative percentage.

i'm just running sysprof to see whats behind the curtains.

pavel

Re: Profiling results of scrolling through the Users Guide

[Pavel Sanda]

Pavel Sanda wrote:
 in short
 total:
 /usr/bin/X60%
 kernel31
 lyx   30

tracking down these 30 (but now in trunk):
16 goes for bv::showcursor and 8.7 to buf::updatemacros
3.4 to buf::changed.

most part (13) from 16 of showcursor boils down to drawparagraph.
but i guess the real bottleneck is not in lyx itself.

btw after the few minutes with sysprof i find its UI
very relieving and productive compared to the work with
gprof and its output.

pavel

Re: Profiling results of scrolling through the Users Guide

[Stephan Witt]

Am 10.06.2011 um 03:00 schrieb Richard Heck:

> On 06/09/2011 04:03 PM, Stephan Witt wrote:
>> Am 09.06.2011 um 20:21 schrieb Peter Kümmel:
>> 
>>> On 09.06.2011 08:12, Stephan Witt wrote:
 To investigate the recently mentioned scrolling problems I did some 
 profiling on my machine.
 See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html
 
 Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk)
 but it's interesting too. To scroll with Page-Down through the Users Guide 
 completely
 I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there 
 are images,
 tables and math. I did this twice. The first time with drawing of text 
 fragments and
 the 2nd time with single character drawing.
 
 While doing this I collected the time profile with Shark, the profiler 
 tool of Xcode.
 
 The most interesting observation I've made is: most of the time LyX is 
 busy with other
 things - not with screen drawing. The scroll operation cost is 5% for the 
 first and 15%
 for the second variant of drawing.
 The other things are thread and socket management and QProcess's doing.
 
 Stephan
 
>>> OK, it is Enrico's job to ask for, but could rerun the test with 
>>> USE_QPROCESS undefined?
>>> 
>>> Peter
>> There is no difference in response time. Scroll speed is the same.
>> The numbers are changing a little bit, perhaps it's a little bit faster.
>> But it's far from a valuable performance gain.
>> 
> I suspect, but hardly know, that in this case QProcess is simply being used 
> to launch things like graphics conversions, and it would be shocking if using 
> it instead of whatever we use instead was the issue here.

I'm lost with this too. I suspect, QProcess is doing some work every time, e. 
g. querying for lost children.
The conversion of graphics shouldn't happen, all of them are cached already. Or 
am I missing something?
In fact, I'm using the Users Guide for my tests regularly.
 
> I suspect that the issue relates more to what we have to do every time the 
> screen moves, and I believe we do that---e.g., recalculate metrics prior to 
> redrawing the screen, which may involve a buffer update, etc, etc---each time 
> new material appears on the screen, which could be every 0.1 seconds or so if 
> you are scrolling quickly, or holding down PageDn. A shot in the dark: Could 
> one interrupt these processes when a new scroll event happens? Why finish 
> calculating the metrics when we know they are about to be irrelevant?

But metrics computation looks innocent in the profiles.

Am 10.06.2011 um 01:42 schrieb Pavel Sanda:

> Stephan Witt wrote:
>> To investigate the recently mentioned scrolling problems I did some 
>> profiling on my machine.
>> See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html
> 
> i'm afraid we need exactly the setup where X is the main consumer.

Agreed. I think the combination of this Xserver and current LyX behaves 
sub-optimal.
On my Mac and my Linux running in VMware I don't have this 

> 
>> Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk) 
>> but it's interesting too. To scroll with Page-Down through the Users Guide 
>> completely 
>> I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there 
>> are images,
>> tables and math. I did this twice. The first time with drawing of text 
>> fragments and
>> the 2nd time with single character drawing. 
>> 
>> While doing this I collected the time profile with Shark, the profiler tool 
>> of Xcode.
>> 
>> The most interesting observation I've made is: most of the time LyX is busy 
>> with other
>> things - not with screen drawing. The scroll operation cost is 5% for the 
>> first and 15%
>> for the second variant of drawing.
>> The other things are thread and socket management and QProcess's doing.
> 
> dont know shark but i guess this is misinterpretation. socket and thread 
> managment 
> look as main consumers just because the percentage is cumulative, no? (ie all 
> the computation
> which happens under lyx::start will be automatically added to its callers - 
> socket)

Yes, maybe. There is an option in Shark to add system calls costs and code 
without debug info to there callers.

When using it I cannot see QProcess and socket ops anymore.
I guess it's cumulated in the 23.8% for lyx::frontend::GuiApplication::exec() 
then.

Stephan

The statistics excerpt:

Self+Children
0.0%100.0%  main
0.0%99.9%lyx::LyX::exec(int&, char**)
23.8%   94.8% lyx::frontend::GuiApplication::exec()
0.7%62.2%  lyx::frontend::GuiApplication::notify(QObject*, QEvent*)
0.0%51.8%   
lyx::frontend::GuiProgressView::qt_metacall(QMetaObject::Call, int, void**)
0.9%51.8%lyx::frontend::GuiProgressView::appendLyXErrText(QString 
const&)
1.9%50.9% lyx::frontend::GuiApplication::notify(QObject*, QEvent*)
0.0%

Re: Profiling results of scrolling through the Users Guide

[Pavel Sanda]

Stephan Witt wrote:
> > dont know shark but i guess this is misinterpretation. socket and thread 
> > managment 
> > look as main consumers just because the percentage is cumulative, no? (ie 
> > all the computation
> > which happens under lyx::start will be automatically added to its callers - 
> > socket)
> 
> Yes, maybe. There is an option in Shark to add system calls costs and code 
> without debug info to there callers.

i think something can be guessed when looking on two stats - one for self one 
for cumulative percentage.

i'm just running sysprof to see whats behind the curtains.

pavel

Re: Profiling results of scrolling through the Users Guide

[Pavel Sanda]

Pavel Sanda wrote:
> in short
> total:
> /usr/bin/X60%
> kernel31
> lyx   30

tracking down these 30 (but now in trunk):
16 goes for bv::showcursor and 8.7 to buf::updatemacros
3.4 to buf::changed.

most part (13) from 16 of showcursor boils down to drawparagraph.
but i guess the real bottleneck is not in lyx itself.

btw after the few minutes with sysprof i find its UI
very relieving and productive compared to the work with
gprof and its output.

pavel

Re: Profiling results of scrolling through the Users Guide

[Peter Kümmel]

On 09.06.2011 08:12, Stephan Witt wrote:

To investigate the recently mentioned scrolling problems I did some profiling 
on my machine.
See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html

Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk)
but it's interesting too. To scroll with Page-Down through the Users Guide 
completely
I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there are 
images,
tables and math. I did this twice. The first time with drawing of text 
fragments and
the 2nd time with single character drawing.

While doing this I collected the time profile with Shark, the profiler tool of 
Xcode.

The most interesting observation I've made is: most of the time LyX is busy 
with other
things - not with screen drawing. The scroll operation cost is 5% for the first 
and 15%
for the second variant of drawing.
The other things are thread and socket management and QProcess's doing.

Stephan



OK, it is Enrico's job to ask for, but could rerun the test with USE_QPROCESS 
undefined?

Peter



* Overall summary:
40.6%   libSystem.B.dylib   thread_start
40.6%   libSystem.B.dylib_pthread_start
23.4%   CoreFoundation__CFSocketManager
17.2%   QtCoreQThreadPrivate::start(void*) { that's QProcess }
34.9%   libSystem.B.dylib   start_wqthread
24.4%   LyX start { that's LyX's main }
0.0%libSystem.B.dylib   exit
0.0%dyld_dyld_start
0.0%libSystem.B.dylib   _exit

* Some excerpts (version A):
5.5%QtGui   QAbstractScrollArea::event(QEvent*)
3.7%LyX  lyx::frontend::WorkAreaManager::redrawAll(bool)
1.0%LyX lyx::Buffer::updateMacros() const
2.5%LyX lyx::frontend::GuiView::loadDocument(lyx::support::FileName 
const, bool)

* Some excerpts (version B):
14.4%   QtGui   QAbstractScrollArea::event(QEvent*)
12.0%   LyX  lyx::frontend::WorkAreaManager::redrawAll(bool)
1.3%LyX lyx::Buffer::updateMacros() const

* The more detailed reports:

Re: Profiling results of scrolling through the Users Guide

[Peter Kümmel]

On 09.06.2011 20:21, Peter Kümmel wrote:

On 09.06.2011 08:12, Stephan Witt wrote:

To investigate the recently mentioned scrolling problems I did some profiling 
on my machine.
See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html

Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk)
but it's interesting too. To scroll with Page-Down through the Users Guide 
completely
I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there are 
images,
tables and math. I did this twice. The first time with drawing of text 
fragments and
the 2nd time with single character drawing.

While doing this I collected the time profile with Shark, the profiler tool of 
Xcode.

The most interesting observation I've made is: most of the time LyX is busy 
with other
things - not with screen drawing. The scroll operation cost is 5% for the first 
and 15%
for the second variant of drawing.
The other things are thread and socket management and QProcess's doing.

Stephan



OK, it is Enrico's job to ask for, but could rerun the test with USE_QPROCESS 
undefined?



Undefining USE_QPROCESS has no effect, tested it.
But I don't know how to interpret the profile.

Peter





* Overall summary:
40.6%   libSystem.B.dylib   thread_start
40.6%   libSystem.B.dylib_pthread_start
23.4%   CoreFoundation__CFSocketManager
17.2%   QtCoreQThreadPrivate::start(void*) { that's QProcess }
34.9%   libSystem.B.dylib   start_wqthread
24.4%   LyX start { that's LyX's main }
0.0%libSystem.B.dylib   exit
0.0%dyld_dyld_start
0.0%libSystem.B.dylib   _exit

* Some excerpts (version A):
5.5%QtGui   QAbstractScrollArea::event(QEvent*)
3.7%LyX  lyx::frontend::WorkAreaManager::redrawAll(bool)
1.0%LyX lyx::Buffer::updateMacros() const
2.5%LyX lyx::frontend::GuiView::loadDocument(lyx::support::FileName 
const, bool)

* Some excerpts (version B):
14.4%   QtGui   QAbstractScrollArea::event(QEvent*)
12.0%   LyX  lyx::frontend::WorkAreaManager::redrawAll(bool)
1.3%LyX lyx::Buffer::updateMacros() const

* The more detailed reports:

Re: Profiling results of scrolling through the Users Guide

[Stephan Witt]

Am 09.06.2011 um 20:21 schrieb Peter Kümmel:

 On 09.06.2011 08:12, Stephan Witt wrote:
 To investigate the recently mentioned scrolling problems I did some 
 profiling on my machine.
 See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html
 
 Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk)
 but it's interesting too. To scroll with Page-Down through the Users Guide 
 completely
 I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there 
 are images,
 tables and math. I did this twice. The first time with drawing of text 
 fragments and
 the 2nd time with single character drawing.
 
 While doing this I collected the time profile with Shark, the profiler tool 
 of Xcode.
 
 The most interesting observation I've made is: most of the time LyX is busy 
 with other
 things - not with screen drawing. The scroll operation cost is 5% for the 
 first and 15%
 for the second variant of drawing.
 The other things are thread and socket management and QProcess's doing.
 
 Stephan
 
 
 OK, it is Enrico's job to ask for, but could rerun the test with USE_QPROCESS 
 undefined?
 
 Peter

There is no difference in response time. Scroll speed is the same.
The numbers are changing a little bit, perhaps it's a little bit faster.
But it's far from a valuable performance gain.

BTW, to undefine USE_QPROCESS with cmake I have to change the source!?

With undefined USE_QPROCESS I get:

* summary
39.3%   libSystem.B.dylib   start_wqthread
31.1%   LyX start
31.1%   LyX  main
31.1%   LyX   lyx::LyX::exec(int, char**)
29.5%   LyXlyx::frontend::GuiApplication::exec()
29.5%   QtCore  QCoreApplication::exec()
29.4%   QtCore   QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag)
29.5%   libSystem.B.dylib   thread_start

* excerpt
18.7%   QtGuiQAbstractScrollArea::event(QEvent*)
18.7%   QtGuiQFrame::event(QEvent*)
18.7%   QtGuiQWidget::event(QEvent*)
...
15.5%   LyX  lyx::Buffer::changed(bool) const
15.5%   LyX lyx::frontend::WorkAreaManager::redrawAll(bool)
15.5%   LyX  lyx::frontend::GuiWorkArea::redraw(bool) 
-
1.7%LyXlyx::BufferView::processUpdateFlags(lyx::Update::flags)
1.7%LyX lyx::Buffer::updateMacros() const

Stephan

# Report 3 - Session 1 - Time Profile (All Thread States) of LyX
SharkProfileViewer
# Generated from the visible portion of the outline view
- 39.3%, start_wqthread, libSystem.B.dylib
+ 31.1%, start, LyX
| + 31.1%, main, LyX
| | + 31.1%, lyx::LyX::exec(int, char**), LyX
| | | + 29.5%, lyx::frontend::GuiApplication::exec(), LyX
| | | | + 29.5%, QCoreApplication::exec(), QtCore
| | | | | + 29.4%, QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag), 
QtCore
| | | | | | + 29.4%, 
QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag), QtCore
| | | | | | | + 29.4%, 
QEventDispatcherMac::processEvents(QFlagsQEventLoop::ProcessEventsFlag), QtGui
| | | | | | | | + 29.4%, -[NSApplication run], AppKit
| | | | | | | | | + 18.9%, -[NSApplication sendEvent:], AppKit
| | | | | | | | | | + 18.8%, -[QCocoaWindow sendEvent:], QtGui
| | | | | | | | | | | + 18.8%, -[NSWindow sendEvent:], AppKit
| | | | | | | | | | | | + 18.8%, -[QCocoaView keyDown:], QtGui
| | | | | | | | | | | | | + 18.8%, qt_dispatchKeyEvent(void*, QWidget*), QtGui
| | | | | | | | | | | | | | + 18.7%, 
QKeyMapperPrivate::translateKeyEvent(QWidget*, OpaqueEventHandlerCallRef*, 
OpaqueEventRef*, void*, bool), QtGui
| | | | | | | | | | | | | | | + 18.7%, QKeyMapper::sendKeyEvent(QWidget*, bool, 
QEvent::Type, int, QFlagsQt::KeyboardModifier, QString const, bool, int, 
unsigned int, unsigned int, unsigned int, bool*), QtGui
| | | | | | | | | | | | | | | | + 18.7%, qt_sendSpontaneousEvent(QObject*, 
QEvent*), QtGui
| | | | | | | | | | | | | | | | | + 18.7%, 
QCoreApplication::notifyInternal(QObject*, QEvent*), QtCore
| | | | | | | | | | | | | | | | | | + 18.7%, 
lyx::frontend::GuiApplication::notify(QObject*, QEvent*), LyX
| | | | | | | | | | | | | | | | | | | + 18.7%, QApplication::notify(QObject*, 
QEvent*), QtGui
| | | | | | | | | | | | | | | | | | | | + 18.7%, 
QApplicationPrivate::notify_helper(QObject*, QEvent*), QtGui
| | | | | | | | | | | | | | | | | | | | | + 18.7%, 
lyx::frontend::GuiWorkArea::event(QEvent*), LyX
| | | | | | | | | | | | | | | | | | | | | | + 18.7%, 
QAbstractScrollArea::event(QEvent*), QtGui
| | | | | | | | | | | | | | | | | | | | | | | + 18.7%, QFrame::event(QEvent*), 
QtGui
| | | | | | | | | | | | | | | | | | | | | | | | + 18.7%, 
QWidget::event(QEvent*), QtGui
| | | | | | | | | | | | | | | | | | | | | | | | | + 18.7%, 
lyx::frontend::GuiWorkArea::keyPressEvent(QKeyEvent*), LyX
| | | | | | | | | | | | | | | | | | | | | | | | | | + 18.7%, 
lyx::frontend::GuiWorkArea::processKeySym(lyx::KeySymbol const, 
lyx::KeyModifier), LyX
| | | | | | | | | | | | | | | | | | | | | | | | | | | + 18.7%, 
lyx::frontend::GuiApplication::processKeySym(lyx::KeySymbol const, 
lyx::KeyModifier), LyX
| | | | | | | | | | | | | | 

Re: Profiling results of scrolling through the Users Guide

[Pavel Sanda]

Stephan Witt wrote:
 To investigate the recently mentioned scrolling problems I did some profiling 
 on my machine.
 See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html

i'm afraid we need exactly the setup where X is the main consumer.

 Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk) 
 but it's interesting too. To scroll with Page-Down through the Users Guide 
 completely 
 I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there 
 are images,
 tables and math. I did this twice. The first time with drawing of text 
 fragments and
 the 2nd time with single character drawing. 
 
 While doing this I collected the time profile with Shark, the profiler tool 
 of Xcode.
 
 The most interesting observation I've made is: most of the time LyX is busy 
 with other
 things - not with screen drawing. The scroll operation cost is 5% for the 
 first and 15%
 for the second variant of drawing.
 The other things are thread and socket management and QProcess's doing.

dont know shark but i guess this is misinterpretation. socket and thread 
managment 
look as main consumers just because the percentage is cumulative, no? (ie all 
the computation
which happens under lyx::start will be automatically added to its callers - 
socketthread)

pavel

Re: Profiling results of scrolling through the Users Guide

[Richard Heck]

On 06/09/2011 04:03 PM, Stephan Witt wrote:

Am 09.06.2011 um 20:21 schrieb Peter Kümmel:


On 09.06.2011 08:12, Stephan Witt wrote:

To investigate the recently mentioned scrolling problems I did some profiling 
on my machine.
See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html

Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk)
but it's interesting too. To scroll with Page-Down through the Users Guide 
completely
I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there are 
images,
tables and math. I did this twice. The first time with drawing of text 
fragments and
the 2nd time with single character drawing.

While doing this I collected the time profile with Shark, the profiler tool of 
Xcode.

The most interesting observation I've made is: most of the time LyX is busy 
with other
things - not with screen drawing. The scroll operation cost is 5% for the first 
and 15%
for the second variant of drawing.
The other things are thread and socket management and QProcess's doing.

Stephan


OK, it is Enrico's job to ask for, but could rerun the test with USE_QPROCESS 
undefined?

Peter

There is no difference in response time. Scroll speed is the same.
The numbers are changing a little bit, perhaps it's a little bit faster.
But it's far from a valuable performance gain.

I suspect, but hardly know, that in this case QProcess is simply being 
used to launch things like graphics conversions, and it would be 
shocking if using it instead of whatever we use instead was the issue 
here. I suspect that the issue relates more to what we have to do every 
time the screen moves, and I believe we do that---e.g., recalculate 
metrics prior to redrawing the screen, which may involve a buffer 
update, etc, etc---each time new material appears on the screen, which 
could be every 0.1 seconds or so if you are scrolling quickly, or 
holding down PageDn. A shot in the dark: Could one interrupt these 
processes when a new scroll event happens? Why finish calculating the 
metrics when we know they are about to be irrelevant?


Richard

Re: Profiling results of scrolling through the Users Guide

[Peter Kümmel]

On 09.06.2011 08:12, Stephan Witt wrote:

To investigate the recently mentioned scrolling problems I did some profiling 
on my machine.
See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html

Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk)
but it's interesting too. To scroll with Page-Down through the Users Guide 
completely
I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there are 
images,
tables and math. I did this twice. The first time with drawing of text 
fragments and
the 2nd time with single character drawing.

While doing this I collected the time profile with Shark, the profiler tool of 
Xcode.

The most interesting observation I've made is: most of the time LyX is busy 
with other
things - not with screen drawing. The scroll operation cost is 5% for the first 
and 15%
for the second variant of drawing.
The other things are thread and socket management and QProcess's doing.

Stephan



OK, it is Enrico's job to ask for, but could rerun the test with USE_QPROCESS 
undefined?

Peter



* Overall summary:
40.6%   libSystem.B.dylib   thread_start
40.6%   libSystem.B.dylib_pthread_start
23.4%   CoreFoundation__CFSocketManager
17.2%   QtCoreQThreadPrivate::start(void*) { that's QProcess }
34.9%   libSystem.B.dylib   start_wqthread
24.4%   LyX start { that's LyX's main }
0.0%libSystem.B.dylib   exit
0.0%dyld_dyld_start
0.0%libSystem.B.dylib   _exit

* Some excerpts (version A):
5.5%QtGui   QAbstractScrollArea::event(QEvent*)
3.7%LyX  lyx::frontend::WorkAreaManager::redrawAll(bool)
1.0%LyX lyx::Buffer::updateMacros() const
2.5%LyX lyx::frontend::GuiView::loadDocument(lyx::support::FileName 
const&, bool)

* Some excerpts (version B):
14.4%   QtGui   QAbstractScrollArea::event(QEvent*)
12.0%   LyX  lyx::frontend::WorkAreaManager::redrawAll(bool)
1.3%LyX lyx::Buffer::updateMacros() const

* The more detailed reports:

Re: Profiling results of scrolling through the Users Guide

[Peter Kümmel]

On 09.06.2011 20:21, Peter Kümmel wrote:

On 09.06.2011 08:12, Stephan Witt wrote:

To investigate the recently mentioned scrolling problems I did some profiling 
on my machine.
See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html

Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk)
but it's interesting too. To scroll with Page-Down through the Users Guide 
completely
I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there are 
images,
tables and math. I did this twice. The first time with drawing of text 
fragments and
the 2nd time with single character drawing.

While doing this I collected the time profile with Shark, the profiler tool of 
Xcode.

The most interesting observation I've made is: most of the time LyX is busy 
with other
things - not with screen drawing. The scroll operation cost is 5% for the first 
and 15%
for the second variant of drawing.
The other things are thread and socket management and QProcess's doing.

Stephan



OK, it is Enrico's job to ask for, but could rerun the test with USE_QPROCESS 
undefined?



Undefining USE_QPROCESS has no effect, tested it.
But I don't know how to interpret the profile.

Peter





* Overall summary:
40.6%   libSystem.B.dylib   thread_start
40.6%   libSystem.B.dylib_pthread_start
23.4%   CoreFoundation__CFSocketManager
17.2%   QtCoreQThreadPrivate::start(void*) { that's QProcess }
34.9%   libSystem.B.dylib   start_wqthread
24.4%   LyX start { that's LyX's main }
0.0%libSystem.B.dylib   exit
0.0%dyld_dyld_start
0.0%libSystem.B.dylib   _exit

* Some excerpts (version A):
5.5%QtGui   QAbstractScrollArea::event(QEvent*)
3.7%LyX  lyx::frontend::WorkAreaManager::redrawAll(bool)
1.0%LyX lyx::Buffer::updateMacros() const
2.5%LyX lyx::frontend::GuiView::loadDocument(lyx::support::FileName 
const&, bool)

* Some excerpts (version B):
14.4%   QtGui   QAbstractScrollArea::event(QEvent*)
12.0%   LyX  lyx::frontend::WorkAreaManager::redrawAll(bool)
1.3%LyX lyx::Buffer::updateMacros() const

* The more detailed reports:

Re: Profiling results of scrolling through the Users Guide

[Stephan Witt]

Am 09.06.2011 um 20:21 schrieb Peter Kümmel:

> On 09.06.2011 08:12, Stephan Witt wrote:
>> To investigate the recently mentioned scrolling problems I did some 
>> profiling on my machine.
>> See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html
>> 
>> Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk)
>> but it's interesting too. To scroll with Page-Down through the Users Guide 
>> completely
>> I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there 
>> are images,
>> tables and math. I did this twice. The first time with drawing of text 
>> fragments and
>> the 2nd time with single character drawing.
>> 
>> While doing this I collected the time profile with Shark, the profiler tool 
>> of Xcode.
>> 
>> The most interesting observation I've made is: most of the time LyX is busy 
>> with other
>> things - not with screen drawing. The scroll operation cost is 5% for the 
>> first and 15%
>> for the second variant of drawing.
>> The other things are thread and socket management and QProcess's doing.
>> 
>> Stephan
>> 
> 
> OK, it is Enrico's job to ask for, but could rerun the test with USE_QPROCESS 
> undefined?
> 
> Peter

There is no difference in response time. Scroll speed is the same.
The numbers are changing a little bit, perhaps it's a little bit faster.
But it's far from a valuable performance gain.

BTW, to undefine USE_QPROCESS with cmake I have to change the source!?

With undefined USE_QPROCESS I get:

* summary
39.3%   libSystem.B.dylib   start_wqthread
31.1%   LyX start
31.1%   LyX  main
31.1%   LyX   lyx::LyX::exec(int&, char**)
29.5%   LyXlyx::frontend::GuiApplication::exec()
29.5%   QtCore  QCoreApplication::exec()
29.4%   QtCore   QEventLoop::exec(QFlags)
29.5%   libSystem.B.dylib   thread_start

* excerpt
18.7%   QtGuiQAbstractScrollArea::event(QEvent*)
18.7%   QtGuiQFrame::event(QEvent*)
18.7%   QtGuiQWidget::event(QEvent*)
...
15.5%   LyX  lyx::Buffer::changed(bool) const
15.5%   LyX lyx::frontend::WorkAreaManager::redrawAll(bool)
15.5%   LyX  lyx::frontend::GuiWorkArea::redraw(bool) 
-
1.7%LyXlyx::BufferView::processUpdateFlags(lyx::Update::flags)
1.7%LyX lyx::Buffer::updateMacros() const

Stephan

# Report 3 - Session 1 - Time Profile (All Thread States) of LyX
SharkProfileViewer
# Generated from the visible portion of the outline view
- 39.3%, start_wqthread, libSystem.B.dylib
+ 31.1%, start, LyX
| + 31.1%, main, LyX
| | + 31.1%, lyx::LyX::exec(int&, char**), LyX
| | | + 29.5%, lyx::frontend::GuiApplication::exec(), LyX
| | | | + 29.5%, QCoreApplication::exec(), QtCore
| | | | | + 29.4%, QEventLoop::exec(QFlags), 
QtCore
| | | | | | + 29.4%, 
QEventLoop::processEvents(QFlags), QtCore
| | | | | | | + 29.4%, 
QEventDispatcherMac::processEvents(QFlags), QtGui
| | | | | | | | + 29.4%, -[NSApplication run], AppKit
| | | | | | | | | + 18.9%, -[NSApplication sendEvent:], AppKit
| | | | | | | | | | + 18.8%, -[QCocoaWindow sendEvent:], QtGui
| | | | | | | | | | | + 18.8%, -[NSWindow sendEvent:], AppKit
| | | | | | | | | | | | + 18.8%, -[QCocoaView keyDown:], QtGui
| | | | | | | | | | | | | + 18.8%, qt_dispatchKeyEvent(void*, QWidget*), QtGui
| | | | | | | | | | | | | | + 18.7%, 
QKeyMapperPrivate::translateKeyEvent(QWidget*, OpaqueEventHandlerCallRef*, 
OpaqueEventRef*, void*, bool), QtGui
| | | | | | | | | | | | | | | + 18.7%, QKeyMapper::sendKeyEvent(QWidget*, bool, 
QEvent::Type, int, QFlags, QString const&, bool, int, 
unsigned int, unsigned int, unsigned int, bool*), QtGui
| | | | | | | | | | | | | | | | + 18.7%, qt_sendSpontaneousEvent(QObject*, 
QEvent*), QtGui
| | | | | | | | | | | | | | | | | + 18.7%, 
QCoreApplication::notifyInternal(QObject*, QEvent*), QtCore
| | | | | | | | | | | | | | | | | | + 18.7%, 
lyx::frontend::GuiApplication::notify(QObject*, QEvent*), LyX
| | | | | | | | | | | | | | | | | | | + 18.7%, QApplication::notify(QObject*, 
QEvent*), QtGui
| | | | | | | | | | | | | | | | | | | | + 18.7%, 
QApplicationPrivate::notify_helper(QObject*, QEvent*), QtGui
| | | | | | | | | | | | | | | | | | | | | + 18.7%, 
lyx::frontend::GuiWorkArea::event(QEvent*), LyX
| | | | | | | | | | | | | | | | | | | | | | + 18.7%, 
QAbstractScrollArea::event(QEvent*), QtGui
| | | | | | | | | | | | | | | | | | | | | | | + 18.7%, QFrame::event(QEvent*), 
QtGui
| | | | | | | | | | | | | | | | | | | | | | | | + 18.7%, 
QWidget::event(QEvent*), QtGui
| | | | | | | | | | | | | | | | | | | | | | | | | + 18.7%, 
lyx::frontend::GuiWorkArea::keyPressEvent(QKeyEvent*), LyX
| | | | | | | | | | | | | | | | | | | | | | | | | | + 18.7%, 
lyx::frontend::GuiWorkArea::processKeySym(lyx::KeySymbol const&, 
lyx::KeyModifier), LyX
| | | | | | | | | | | | | | | | | | | | | | | | | | | + 18.7%, 
lyx::frontend::GuiApplication::processKeySym(lyx::KeySymbol const&, 
lyx::KeyModifier), LyX
| | | | | | | | | | | | | | | | | | | | | | | | | | | | + 18.7%, 

Re: Profiling results of scrolling through the Users Guide

[Pavel Sanda]

Stephan Witt wrote:
> To investigate the recently mentioned scrolling problems I did some profiling 
> on my machine.
> See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html

i'm afraid we need exactly the setup where X is the main consumer.

> Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk) 
> but it's interesting too. To scroll with Page-Down through the Users Guide 
> completely 
> I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there 
> are images,
> tables and math. I did this twice. The first time with drawing of text 
> fragments and
> the 2nd time with single character drawing. 
> 
> While doing this I collected the time profile with Shark, the profiler tool 
> of Xcode.
> 
> The most interesting observation I've made is: most of the time LyX is busy 
> with other
> things - not with screen drawing. The scroll operation cost is 5% for the 
> first and 15%
> for the second variant of drawing.
> The other things are thread and socket management and QProcess's doing.

dont know shark but i guess this is misinterpretation. socket and thread 
managment 
look as main consumers just because the percentage is cumulative, no? (ie all 
the computation
which happens under lyx::start will be automatically added to its callers - 
socket)

pavel

Re: Profiling results of scrolling through the Users Guide

[Richard Heck]

On 06/09/2011 04:03 PM, Stephan Witt wrote:

Am 09.06.2011 um 20:21 schrieb Peter Kümmel:


On 09.06.2011 08:12, Stephan Witt wrote:

To investigate the recently mentioned scrolling problems I did some profiling 
on my machine.
See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html

Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk)
but it's interesting too. To scroll with Page-Down through the Users Guide 
completely
I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there are 
images,
tables and math. I did this twice. The first time with drawing of text 
fragments and
the 2nd time with single character drawing.

While doing this I collected the time profile with Shark, the profiler tool of 
Xcode.

The most interesting observation I've made is: most of the time LyX is busy 
with other
things - not with screen drawing. The scroll operation cost is 5% for the first 
and 15%
for the second variant of drawing.
The other things are thread and socket management and QProcess's doing.

Stephan


OK, it is Enrico's job to ask for, but could rerun the test with USE_QPROCESS 
undefined?

Peter

There is no difference in response time. Scroll speed is the same.
The numbers are changing a little bit, perhaps it's a little bit faster.
But it's far from a valuable performance gain.

I suspect, but hardly know, that in this case QProcess is simply being 
used to launch things like graphics conversions, and it would be 
shocking if using it instead of whatever we use instead was the issue 
here. I suspect that the issue relates more to what we have to do every 
time the screen moves, and I believe we do that---e.g., recalculate 
metrics prior to redrawing the screen, which may involve a buffer 
update, etc, etc---each time new material appears on the screen, which 
could be every 0.1 seconds or so if you are scrolling quickly, or 
holding down PageDn. A shot in the dark: Could one interrupt these 
processes when a new scroll event happens? Why finish calculating the 
metrics when we know they are about to be irrelevant?


Richard