On Fri, Oct 17, 2003 at 12:07:18PM +0200, Andre Poenitz wrote:
> Most notably, the 'fill' computation could be merged with the
> 'rowBreakPoint' stuff as it alomost does the same thing. This way
> only half of the width() calls would be needed...
If you go anywhere near row-breaking please make
On Fri, Oct 17, 2003 at 11:27:03AM +0200, Lars Gullik Bjønnes wrote:
> | Switching between two UserGuides is a bit slow, but acceptable.
> | However on a P-III 500 (f.ex.) the switching would be really anoying.
> | (I wouldn't think about a P-II...)
>
> Switching seems better (tiny bit) as well. p
acceptable.
| However on a P-III 500 (f.ex.) the switching would be really anoying.
| (I wouldn't think about a P-II...)
Switching seems better (tiny bit) as well. perhaps only somehting I
feel.
textcache removal forthcomming.
--
Lgb
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Could we please commit the textcache removal or deactivation patch
| please?
I'll do it right after I have tested my laptop again. two hours max.
--
Lgb
Could we please commit the textcache removal or deactivation patch
please?
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
On Thu, 16 Oct 2003, Christian Ridderström wrote:
> On Thu, 16 Oct 2003, Lars Gullik Bjønnes wrote:
>
> > I'd really like to know, how slow does a computer need to be before
> > the buffer switch get unbearably slow. So some tests on P-III's and
> > P-II's would be nice (slower than that I do not
On Thu, Oct 16, 2003 at 05:46:48PM +0200, Lars Gullik Bjønnes wrote:
> | Ok. When loading the UserGuide this change alone reduces
> | LyXText::getRowNearY share from 31.6 to 3.4 percent.
> >
> | So this is a speedup of 10 for this function translating
> | to more than 20% total speed gain.
>
> do
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 16, 2003 at 04:31:29PM +0200, Andre' Poenitz wrote:
>> Currently most time (currently compiling with -pg to get hard numbers)
>> is spend in accessing the row's y cache. If this is changed to a
>> per-paragraph y cache and a row-y offset in t
On Thu, Oct 16, 2003 at 04:31:29PM +0200, Andre' Poenitz wrote:
> Currently most time (currently compiling with -pg to get hard numbers)
> is spend in accessing the row's y cache. If this is changed to a
> per-paragraph y cache and a row-y offset in that paragraph we should see
> a speed up in the
On Thu, Oct 16, 2003 at 04:18:23PM +0200, Lars Gullik Bjønnes wrote:
> This is with a P-III 1000Mhz. (lot of memory, but a laptop so the
> io-subsystem is really bad..)
>
> time ./src/lyx -x 'lyx-quit ;'
>
> real0m0.853s
> user0m0.460s
> sys 0m0.020s
>
>
> time ./src/lyx -x 'command
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Andre Poenitz <[EMAIL PROTECTED]> writes:
>
| | On Thu, Oct 16, 2003 at 12:14:58PM +0200, Christian Ridderström wrote:
>>> On Thu, 16 Oct 2003, Lars Gullik Bjønnes wrote:
>>>
>>> > I'd really like to know, how slow does a computer need to be befor
ving you a subjective opinion, do you want me to
>> test it in a specific way?
>
| Just switching between two copies of the UserGuide should be fine.
This is probably just Alfredos patch updated. I also remove the
textcache files.
When we get some test results I will just apply this one.
(why
On Thu, Oct 16, 2003 at 12:14:58PM +0200, Christian Ridderström wrote:
> On Thu, 16 Oct 2003, Lars Gullik Bjønnes wrote:
>
> > I'd really like to know, how slow does a computer need to be before
> > the buffer switch get unbearably slow. So some tests on P-III's and
> > P-II's would be nice (slowe
On Thu, 16 Oct 2003, Lars Gullik Bjønnes wrote:
> I'd really like to know, how slow does a computer need to be before
> the buffer switch get unbearably slow. So some tests on P-III's and
> P-II's would be nice (slower than that I do not care too much about.)
I've got a 300MHz laptop, and I'll te
On Thu, Oct 16, 2003 at 11:46:20AM +0200, Lars Gullik Bjønnes wrote:
> (somehow debugstream is not workign with gcc 3.4 with maximum
> optimization, I will investigate.)
>
> I'd really like to know, how slow does a computer need to be before
> the buffer switch get unbearably slow. So some tests o
On Thu, Oct 16, 2003 at 11:34:55AM +0200, Lars Gullik Bjønnes wrote:
> | Not really. Rebreaking should be a bit faster nowadays, but this
> | exceeds my expectations.
>
> I have a feeling that something fishy is going on. Should the "no text
> in cache" message from BufferView::Pimpl::resizeCurren
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
| | Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
| | | On Thu, Oct 16, 2003 at 11:07:52AM +0200, Lars Gullik Bjønnes wrote:
>>>> This is some results without the textcac
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Andre Poenitz <[EMAIL PROTECTED]> writes:
>
| | On Thu, Oct 16, 2003 at 11:07:52AM +0200, Lars Gullik Bjønnes wrote:
>>> This is some results without the textcache removed.
>>>
>>> time ./src/lyx -x 'lyx
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 16, 2003 at 11:07:52AM +0200, Lars Gullik Bjønnes wrote:
>> This is some results without the textcache removed.
>>
>> time ./src/lyx -x 'lyx-quit'
>>
>> real0m0.313s
>> user0m0.1
ion from 'LyXText in parallel to paragraph list' to
'(map of) LyXText in paragraph list'. So even if the feeling were bad,
this is not final.
> | A text cahce revival would happen on a 'per paragraph list' base, so
> | even if keeping TextCache.[Ch] might be in o
On Thu, Oct 16, 2003 at 11:07:52AM +0200, Lars Gullik Bjønnes wrote:
> This is some results without the textcache removed.
>
> time ./src/lyx -x 'lyx-quit'
>
> real0m0.313s
> user0m0.150s
> sys 0m0.050s
>
>
> time ./src/lyx -x 'comman
t is not yet for sure that we are going to
remove it right now. So we leave the code around until more people can
tell us bout the "new feeling".
| A text cahce revival would happen on a 'per paragraph list' base, so
| even if keeping TextCache.[Ch] might be in order, all the
Andre Poenitz <[EMAIL PROTECTED]> writes:
| This is Alfredo's old 'textcache removal' patch.
>
| With it, buffer cycling between two copies of the UserGuide is
| significantly faster than I can access the View->1/2 menu by mouse and
| about as fast as I can type M-v
On Thu, Oct 16, 2003 at 10:25:52AM +0200, Lars Gullik Bjønnes wrote:
> Just comment out the textcache.add here and delete bv_->text and set
> it to 0.
What's the benefit of keeping dead code?
A text cahce revival would happen on a 'per paragraph list' base, so
even
Andre Poenitz <[EMAIL PROTECTED]> writes:
| This is Alfredo's old 'textcache removal' patch.
>
| With it, buffer cycling between two copies of the UserGuide is
| significantly faster than I can access the View->1/2 menu by mouse and
| about as fast as I can type M-v
This is Alfredo's old 'textcache removal' patch.
With it, buffer cycling between two copies of the UserGuide is
significantly faster than I can access the View->1/2 menu by mouse and
about as fast as I can type M-v 1 or M-v 2.
So even if this is a AMD 1700+ it should be usabl
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, Aug 07, 2003 at 04:52:14PM +0200, Lars Gullik Bj?nnes wrote:
>
>> I nice implication of this might be that we won't need a BufferList
>> anymore (at least not explicit), but keep only open those buffers that
>> has a BufferView.
>
| Eh, how would th
Angus Leeming <[EMAIL PROTECTED]> writes:
| John Levon wrote:
>
>> On Thu, Aug 07, 2003 at 04:52:14PM +0200, Lars Gullik Bj?nnes wrote:
>>
>>> I nice implication of this might be that we won't need a BufferList
>>> anymore (at least not explicit), but keep only open those buffers that
>>> has a B
Has anybody done any kind of profiling to show that this is really
needed?
[I mean, the code is not bad, but this pretty much looks like premature
optimization in the light of 'rebreak much and often'...]
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
n
Angus Leeming <[EMAIL PROTECTED]> writes:
| John Levon wrote:
>
>> On Thu, Aug 07, 2003 at 04:52:14PM +0200, Lars Gullik Bj?nnes wrote:
>>
>>> I nice implication of this might be that we won't need a BufferList
>>> anymore (at least not explicit), but keep only open those buffers that
>>> has a B
On Thu, Aug 07, 2003 at 04:04:35PM +, Angus Leeming wrote:
> Presumably the BufferView would have a
> shared_ptr buffer_;
Oh ok.
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | Has anybody done any kind of profiling to show that this is really
>> | needed?
>>>
>> | [I mean, the code is not bad, but this pretty much looks like premature
>> |
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Has anybody done any kind of profiling to show that this is really
| needed?
>
| [I mean, the code is not bad, but this pretty much looks like premature
| optimization in the light of 'rebreak much and often'...]
It might not be needed after you are don
Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Has anybody done any kind of profiling to show that this is really
> | needed?
>>
> | [I mean, the code is not bad, but this pretty much looks like premature
> | optimization in the light of 'rebreak much and often'...]
On Thu, Aug 07, 2003 at 04:52:14PM +0200, Lars Gullik Bj?nnes wrote:
> I nice implication of this might be that we won't need a BufferList
> anymore (at least not explicit), but keep only open those buffers that
> has a BufferView.
Eh, how would that work ?
john
--
Khendon's Law:
If the same po
John Levon wrote:
> On Thu, Aug 07, 2003 at 04:52:14PM +0200, Lars Gullik Bj?nnes wrote:
>
>> I nice implication of this might be that we won't need a BufferList
>> anymore (at least not explicit), but keep only open those buffers that
>> has a BufferView.
>
> Eh, how would that work ?
>
> john
Angus Leeming wrote:
> As I read it, I think that Lars is saying we could store a BufferViewList.
Note that this is needed in any case (for multiple bufferviews).
Alfredo
37 matches
Mail list logo
