> "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
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars, this is the patch I would like to apply. OK?
Yes, ok.
--
Lgb
Jean-Marc Lasgouttes wrote:
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) to be able to compare the results with the old slow method.
I will continue some testing, but basically it sees to work.
It seem
> "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 de
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
>
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
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
> #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
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 a
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,
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&paste
> job from
> "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 fi
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.
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: updateCounters(cu
> "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 ParIte
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 a
> "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> i
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
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 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 o
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
chan
> "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 o
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 cou
> "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:
>> "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
> "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&paste job from forwardPos, but not stepping over all
Andre> characters, but only over insets.
Yes, but
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 i
> "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
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 updatecounte
29 matches
Mail list logo
