Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Jean-Marc It seems to work well enough. I moved the counter code to
Jean-Marc buffer_funcs.C, since it does not relate to LyXText at all
Jean-Marc now.
Jean-Marc Lars, this is the patch I would like to apply. OK?
I applied it now.
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> It seems to work well enough. I moved the counter code to
Jean-Marc> buffer_funcs.C, since it does not relate to LyXText at all
Jean-Marc> now.
Jean-Marc> Lars, this is the patch I would like to apply. OK?
I
Andreas == Andreas Vox [EMAIL PROTECTED] writes:
Andreas Yes, but that wasn't my question. :-) I just wanted to know
Andreas if I'm just too stupid to produce the delay or if PowerPC is
Andreas genuinely faster. Now that's settled I'd like to know your
Andreas compiler settings, so I can try to
Jean-Marc Lasgouttes wrote:
Yes, but this is not safe if there insets in the paragraph before lastp,
I think.
Ah, you are right. I overlooked that.
Here is a simpler try that does mostly what you propose, but uses
forwardPos() to do the hard work. I kept the old code around (see the
#if 0)
Jean-Marc Lasgouttes wrote:
Jean-Marc To make this faster, I think DocIterator::forwardPar should
Jean-Marc take advantage of the inset list of paragraphs. This is the
Jean-Marc only way to avoid visiting all cursor positions... So each
Jean-Marc cursor slice should keep an up to date
Lars Gullik Bjnnes wrote:
Georg Baum [EMAIL PROTECTED]
writes:
| Jean-Marc Lasgouttes wrote:
Breaking a paragraph in the userguide gives a delay of ~ 1sec on my
2.8GHz Xeon. Not acceptable IMO.
Here is an updated version of the patch (with lyxtext.h this time) for
people who want to
Georg == Georg Baum [EMAIL PROTECTED] writes:
I will continue some testing, but basically it sees to work.
Georg I played a bit with it and it indeed seems to work. It is still
Georg somewhat slow, but I think it is acceptable now.
I ran it a bit under oprofile, and I could not detect
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Lars, this is the patch I would like to apply. OK?
Yes, ok.
--
Lgb
> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes:
Andreas> Yes, but that wasn't my question. :-) I just wanted to know
Andreas> if I'm just too stupid to produce the delay or if PowerPC is
Andreas> genuinely faster. Now that's settled I'd like to know your
Andreas> compiler settings, so
Jean-Marc Lasgouttes wrote:
> Yes, but this is not safe if there insets in the paragraph before lastp,
> I think.
Ah, you are right. I overlooked that.
> Here is a simpler try that does mostly what you propose, but uses
> forwardPos() to do the hard work. I kept the old code around (see the
>
Jean-Marc Lasgouttes wrote:
> Jean-Marc> To make this faster, I think DocIterator::forwardPar should
> Jean-Marc> take advantage of the inset list of paragraphs. This is the
> Jean-Marc> only way to avoid visiting all cursor positions... So each
> Jean-Marc> cursor slice should keep an up to date
Lars Gullik BjÃnnes wrote:
> Georg Baum <[EMAIL PROTECTED]>
> writes:
>
> | Jean-Marc Lasgouttes wrote:
>>
>>> Breaking a paragraph in the userguide gives a delay of ~ 1sec on my
>>> 2.8GHz Xeon. Not acceptable IMO.
>>>
>>> Here is an updated version of the patch (with lyxtext.h this time) for
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> I will continue some testing, but basically it sees to work.
Georg> I played a bit with it and it indeed seems to work. It is still
Georg> somewhat slow, but I think it is acceptable now.
I ran it a bit under oprofile, and I could not
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars, this is the patch I would like to apply. OK?
Yes, ok.
--
Lgb
Jean-Marc Lasgouttes wrote:
Breaking a paragraph in the userguide gives a delay of ~ 1sec on my
2.8GHz Xeon. Not acceptable IMO.
Here is an updated version of the patch (with lyxtext.h this time) for
people who want to play with it.
A debug build (without gprof) gives a similar delay on a
Georg Baum [EMAIL PROTECTED] writes:
| Jean-Marc Lasgouttes wrote:
Breaking a paragraph in the userguide gives a delay of ~ 1sec on my
2.8GHz Xeon. Not acceptable IMO.
Here is an updated version of the patch (with lyxtext.h this time) for
people who want to play with it.
| A debug build
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
To be more precise, 96% of the time spent in updateCounters is due to
ParIterator::operator++(int).
Does this change if you use the preincrement operator instead?
I'm not sure how much overhead comes from the initialisation
of the temporary
Andreas == Andreas Vox [EMAIL PROTECTED] writes:
Andreas Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
To be more precise, 96% of the time spent in updateCounters is due
to ParIterator::operator++(int).
Andreas Does this change if you use the preincrement operator
Andreas instead? I'm not
Am 23.02.2005 um 13:57 schrieb Jean-Marc Lasgouttes:
Andreas Does this change if you use the preincrement operator
Andreas instead? I'm not sure how much overhead comes from the
Andreas initialisation of the temporary ParIterator object.
This is the ++it operator (I may have the notation wrong
Andreas == Andreas Vox [EMAIL PROTECTED] writes:
Andreas Am 23.02.2005 um 13:57 schrieb Jean-Marc Lasgouttes:
Andreas Does this change if you use the preincrement operator
Andreas instead? I'm not sure how much overhead comes from the
Andreas initialisation of the temporary ParIterator object.
Am 23.02.2005 um 18:03 schrieb Jean-Marc Lasgouttes:
Are you sure that you compiled after applying the patch? ;)
Does this look like the correct source:
$ grep updateCounters src/*.C
src/CutAndPaste.C: updateCounters(cur.buffer(), cur);
src/CutAndPaste.C:
Andreas Vox wrote:
Does this look like the correct source:
$ grep updateCounters src/*.C
src/CutAndPaste.C: updateCounters(cur.buffer(), cur);
src/CutAndPaste.C: updateCounters(cur.buffer(), cur);
src/text.C: updateCounters(cur.buffer(), cur);
src/text.C:
Andreas == Andreas Vox [EMAIL PROTECTED] writes:
Andreas Do you have exact instructions for producing the delay? Like
Andreas Go to that paragraph in userguide and hit enter after the
Andreas word X ?
In text2.C, function updateCounters, you have two version of the
function. The first one,
Am Montag, 21. Februar 2005 09:22 schrieb Andre Poenitz:
I think replacing
void DocIterator::forwardPar()
{
forwardPos();
while (!empty() (!inTexted() || pos() != 0))
forwardPos();
}
with something more sensible would be better. Most likely a cutpaste
job from forwardPos,
Am 23.02.2005 um 19:37 schrieb Jean-Marc Lasgouttes:
Andreas == Andreas Vox [EMAIL PROTECTED] writes:
Andreas Do you have exact instructions for producing the delay? Like
Andreas Go to that paragraph in userguide and hit enter after the
Andreas word X ?
In text2.C, function updateCounters, you
Georg Baum wrote:
Am Montag, 21. Februar 2005 09:22 schrieb Andre Poenitz:
The only change that seems to make all the difference is this:
#ifdef SLOW_forwardPar
++tip.pos();
#else
tip.pos() = lastp;
#endif
Yes, but this is not safe if there insets in the paragraph before lastp,
I think.
Here is
Jean-Marc Lasgouttes wrote:
> Breaking a paragraph in the userguide gives a delay of ~ 1sec on my
> 2.8GHz Xeon. Not acceptable IMO.
>
> Here is an updated version of the patch (with lyxtext.h this time) for
> people who want to play with it.
A debug build (without gprof) gives a similar delay
Georg Baum <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
>
>> Breaking a paragraph in the userguide gives a delay of ~ 1sec on my
>> 2.8GHz Xeon. Not acceptable IMO.
>>
>> Here is an updated version of the patch (with lyxtext.h this time) for
>> people who want to play with it.
>
| A
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> To be more precise, 96% of the time spent in updateCounters is due to
> ParIterator::operator++(int).
Does this change if you use the preincrement operator instead?
I'm not sure how much overhead comes from the initialisation
of the
> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes:
Andreas> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> To be more precise, 96% of the time spent in updateCounters is due
>> to ParIterator::operator++(int).
Andreas> Does this change if you use the preincrement operator
Andreas>
Am 23.02.2005 um 13:57 schrieb Jean-Marc Lasgouttes:
Andreas> Does this change if you use the preincrement operator
Andreas> instead? I'm not sure how much overhead comes from the
Andreas> initialisation of the temporary ParIterator object.
This is the ++it operator (I may have the notation wrong
> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes:
Andreas> Am 23.02.2005 um 13:57 schrieb Jean-Marc Lasgouttes:
>>
Andreas> Does this change if you use the preincrement operator
Andreas> instead? I'm not sure how much overhead comes from the
Andreas> initialisation of the temporary
Am 23.02.2005 um 18:03 schrieb Jean-Marc Lasgouttes:
Are you sure that you compiled after applying the patch? ;)
Does this look like the correct source:
$ grep updateCounters src/*.C
src/CutAndPaste.C: updateCounters(cur.buffer(), cur);
src/CutAndPaste.C:
Andreas Vox wrote:
> Does this look like the correct source:
>
> $ grep updateCounters src/*.C
> src/CutAndPaste.C: updateCounters(cur.buffer(), cur);
> src/CutAndPaste.C: updateCounters(cur.buffer(), cur);
> src/text.C: updateCounters(cur.buffer(), cur);
>
> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes:
Andreas> Do you have exact instructions for producing the delay? Like
Andreas> "Go to that paragraph in userguide and hit enter after the
Andreas> word X" ?
In text2.C, function updateCounters, you have two version of the
function. The
Am Montag, 21. Februar 2005 09:22 schrieb Andre Poenitz:
> I think replacing
>
> void DocIterator::forwardPar()
> {
> forwardPos();
> while (!empty() && (!inTexted() || pos() != 0))
>forwardPos();
> }
>
> with something more sensible would be better. Most likely a cut
> job from
Am 23.02.2005 um 19:37 schrieb Jean-Marc Lasgouttes:
"Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes:
Andreas> Do you have exact instructions for producing the delay? Like
Andreas> "Go to that paragraph in userguide and hit enter after the
Andreas> word X" ?
In text2.C, function
Georg Baum wrote:
Am Montag, 21. Februar 2005 09:22 schrieb Andre Poenitz:
The only change that seems to make all the difference is this:
#ifdef SLOW_forwardPar
++tip.pos();
#else
tip.pos() = lastp;
#endif
Yes, but this is not safe if there insets in the paragraph before lastp,
I think.
Here is
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Jean-Marc The following patch modifies updateCounters to recompute
| Jean-Marc the counters recursively for the whooe document everytime.
| Jean-Marc As expected, this is _very_
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars For 1.4.0 I'd rather not fiddle to much with this. If it now
Lars works, then that is good. We can work to speed it up later.
Lars Unless it is _really_ horrible of course.
I'll have to check, but on a gprof instrumented lyx (with
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| Lars For 1.4.0 I'd rather not fiddle to much with this. If it now
| Lars works, then that is good. We can work to speed it up later.
| Lars Unless it is _really_ horrible of course.
| I'll
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Yes, for speed tests a grpof build is not approp. We should
Lars check with an optimized build.
Breaking a paragraph in the userguide gives a delay of ~ 1sec on my
2.8GHz Xeon. Not acceptable IMO.
Here is an updated version of the
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Breaking a paragraph in the userguide gives a delay of ~ 1sec on my
2.8GHz Xeon. Not acceptable IMO.
Can't confirm for PowerMac 1.3 GHz. Breaking a paragraph is instant at
the beginning of UserGuide and ~1/10 sec at the end. I also tried
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
| Jean-Marc> The following patch modifies updateCounters to recompute
| Jean-Marc> the counters recursively for the whooe document everytime.
| Jean-Marc> As expected, this is
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> For 1.4.0 I'd rather not fiddle to much with this. If it now
Lars> works, then that is good. We can work to speed it up later.
Lars> Unless it is _really_ horrible of course.
I'll have to check, but on a gprof instrumented lyx
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> For 1.4.0 I'd rather not fiddle to much with this. If it now
| Lars> works, then that is good. We can work to speed it up later.
| Lars> Unless it is _really_ horrible of
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Yes, for speed tests a grpof build is not approp. We should
Lars> check with an optimized build.
Breaking a paragraph in the userguide gives a delay of ~ 1sec on my
2.8GHz Xeon. Not acceptable IMO.
Here is an updated version
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> Breaking a paragraph in the userguide gives a delay of ~ 1sec on my
> 2.8GHz Xeon. Not acceptable IMO.
Can't confirm for PowerMac 1.3 GHz. Breaking a paragraph is instant at
the beginning of UserGuide and ~1/10 sec at the end. I also tried
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Jean-Marc The following patch modifies updateCounters to recompute
Jean-Marc the counters recursively for the whooe document everytime.
Jean-Marc As expected, this is _very_ expensive on a file like
Jean-Marc UserGuide. The profiler
On Mon, Feb 21, 2005 at 12:03:55AM +0100, Jean-Marc Lasgouttes wrote:
Jean-Marc Lasgouttes wrote:
The situation with counters is still very bad: captions in floats do not
have a label when loading a file. Also, updateCounters renumbers the
whole lyxtext without trying to go into nested insets.
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre I think replacing DocIterator::forwardPar() [...]
Andre with something more sensible would be better. Most likely a
Andre cutpaste job from forwardPos, but not stepping over all
Andre characters, but only over insets.
Yes, but forwardPos
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> The following patch modifies updateCounters to recompute
Jean-Marc> the counters recursively for the whooe document everytime.
Jean-Marc> As expected, this is _very_ expensive on a file like
Jean-Marc> UserGuide. The
On Mon, Feb 21, 2005 at 12:03:55AM +0100, Jean-Marc Lasgouttes wrote:
> Jean-Marc Lasgouttes wrote:
> >The situation with counters is still very bad: captions in floats do not
> >have a label when loading a file. Also, updateCounters renumbers the
> >whole lyxtext without trying to go into nested
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> I think replacing DocIterator::forwardPar() [...]
Andre> with something more sensible would be better. Most likely a
Andre> cut job from forwardPos, but not stepping over all
Andre> characters, but only over insets.
Yes, but
The following patch fixes the infamous 'caption hack'. What it does is
to add an infrastructure that insures that setCounter gets passed a full
iterator from which enclosing figure floats can be found at any level.
The situation with counters is still very bad: captions in floats do not
have a
Jean-Marc Lasgouttes wrote:
The situation with counters is still very bad: captions in floats do not
have a label when loading a file. Also, updateCounters renumbers the
whole lyxtext without trying to go into nested insets. I suspect that
all paragraphs will have to be visited at each
The following patch fixes the infamous 'caption hack'. What it does is
to add an infrastructure that insures that setCounter gets passed a full
iterator from which enclosing figure floats can be found at any level.
The situation with counters is still very bad: captions in floats do not
have a
Jean-Marc Lasgouttes wrote:
The situation with counters is still very bad: captions in floats do not
have a label when loading a file. Also, updateCounters renumbers the
whole lyxtext without trying to go into nested insets. I suspect that
all paragraphs will have to be visited at each
58 matches
Mail list logo
