I used sometime yesterday evening to run gprof with large tables, and
came up with the following patch. I posted it here instead of applying
because it seems so obvious that I suspect I may have misunderstood
something.
The two main problems are:
- InsetTabular::clone() duplicates its
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| I used sometime yesterday evening to run gprof with large tables, and
| came up with the following patch. I posted it here instead of applying
| because it seems so obvious that I suspect I may have misunderstood
| something.
|
| The two main
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | I
Lars used sometime yesterday evening to run gprof with large tables,
Lars and | came up with the following patch. I posted it here instead
Lars of applying | because it seems so obvious
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Or... just cache the LyXText at the begining of the method.
Yes, but is it necessary to somehow check that it is still valid? The
gain is probably not important enough to bother with that anyway. I
just thought that using a map does
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars Or... just cache the LyXText at the begining of the method.
|
| Yes, but is it necessary to somehow check that it is still valid? The
| gain is probably not important enough to
On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
Lars Or... just cache the LyXText at the begining of the method.
Yes, but is it necessary to somehow check that it is still valid? The
gain is probably not important enough to bother with that anyway. I
just thought that using a map does not make
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen Well I don't know about how fast we are but you cannot put
Juergen there a LyXText parameter as the LyXText is allocated inside
Juergen the InsetText and there is one for each BufferView. You're
Juergen right if you say actually we have
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen Would you please test the following patch? It inserts a
Juergen secure caching mechanism into insettext without the need to
Juergen change a lot of code. Do you see differences in execute time?
The code looks good. I'll try it out.
Juergen Vigna [EMAIL PROTECTED] writes:
| On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
|
| Let's say it is showing in the few first lines of gprof output,
| whatever that means. A few percents, which is huge for such a mundane
| task, IMO.
|
| Would you please test the following patch? It
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen Would you please test the following patch? It inserts a
Juergen secure caching mechanism into insettext without the need to
Juergen change a lot of code. Do you see differences in execute time?
I suspect it is not very safe wrt
On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
I suspect it is not very safe wrt InsetText::setParagraphData. The
cached value could become wrong after that. With the patch, getLyXText
is still credited with 3.3% of run time, with a whooping 4705244
Well but what was the % before? Did we gain
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
I suspect it is not very safe wrt InsetText::setParagraphData. The
cached value could become wrong after that. With the patch,
getLyXText is still credited with 3.3% of run time, with a
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
Unfortunately, I do not have this info anymore :( I think it was a
bit higher, but no number.
Juergen Well it would be nice to have a number otherwise we won't see
Juergen if it is map
I used sometime yesterday evening to run gprof with large tables, and
came up with the following patch. I posted it here instead of applying
because it seems so obvious that I suspect I may have misunderstood
something.
The two main problems are:
- InsetTabular::clone() duplicates its
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| I used sometime yesterday evening to run gprof with large tables, and
| came up with the following patch. I posted it here instead of applying
| because it seems so obvious that I suspect I may have misunderstood
| something.
|
| The two main
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I
Lars> used sometime yesterday evening to run gprof with large tables,
Lars> and | came up with the following patch. I posted it here instead
Lars> of applying | because it
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Or... just cache the LyXText at the begining of the method.
Yes, but is it necessary to somehow check that it is still valid? The
gain is probably not important enough to bother with that anyway. I
just thought that using a
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Or... just cache the LyXText at the begining of the method.
|
| Yes, but is it necessary to somehow check that it is still valid? The
| gain is probably not important
On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
> Lars> Or... just cache the LyXText at the begining of the method.
> Yes, but is it necessary to somehow check that it is still valid? The
> gain is probably not important enough to bother with that anyway. I
> just thought that using a map does not
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> Well I don't know about how fast we are but you cannot put
Juergen> there a LyXText parameter as the LyXText is allocated inside
Juergen> the InsetText and there is one for each BufferView. You're
Juergen> right if you say
On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
> Let's say it is showing in the few first lines of gprof output,
> whatever that means. A few percents, which is huge for such a mundane
> task, IMO.
Would you please test the following patch? It inserts a "secure" caching
mechanism into insettext
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> Would you please test the following patch? It inserts a
Juergen> "secure" caching mechanism into insettext without the need to
Juergen> change a lot of code. Do you see differences in execute time?
The code looks good. I'll
Juergen Vigna <[EMAIL PROTECTED]> writes:
| On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
|
| > Let's say it is showing in the few first lines of gprof output,
| > whatever that means. A few percents, which is huge for such a mundane
| > task, IMO.
|
| Would you please test the following patch?
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> Would you please test the following patch? It inserts a
Juergen> "secure" caching mechanism into insettext without the need to
Juergen> change a lot of code. Do you see differences in execute time?
I suspect it is not very
On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
> I suspect it is not very safe wrt InsetText::setParagraphData. The
> cached value could become wrong after that. With the patch, getLyXText
> is still credited with 3.3% of run time, with a whooping 4705244
Well but what was the % before? Did we
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
>> I suspect it is not very safe wrt InsetText::setParagraphData. The
>> cached value could become wrong after that. With the patch,
>> getLyXText is still credited with 3.3% of run
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 29-Jun-2001 Jean-Marc Lasgouttes wrote:
>> Unfortunately, I do not have this info anymore :( I think it was a
>> bit higher, but no number.
Juergen> Well it would be nice to have a number otherwise we won't see
Juergen> if
27 matches
Mail list logo
