> "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
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 labe
30 matches
Mail list logo
