On Sat, Jun 03, 2006 at 02:41:51PM +0200, Georg Baum wrote:
> possible. It turned out that the pointer solution did not really work
> (apart from the exception safety which is not so important because we
> have already the lyxsocket and lyxserver pointers)
Okokok.
Andre'
Am Dienstag, 6. Juni 2006 18:41 schrieb Andre Poenitz:
> On Wed, May 31, 2006 at 10:45:00AM +0200, Jean-Marc Lasgouttes wrote:
> > > "Andre" == Andre Poenitz
<[EMAIL PROTECTED]> writes:
> >
> > Andre> Are we really explicitly calling exit()?
> >
> > Yes, in lyx_gui::exit, which is called in
On Wed, May 31, 2006 at 10:45:00AM +0200, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> Are we really explicitly calling exit()?
>
> Yes, in lyx_gui::exit, which is called in quitLyX. Do you think this
> is a problem?
I am not sure this is an
Georg Baum wrote:
Am Dienstag, 30. Mai 2006 18:06 schrieb Andre Poenitz:
without a static object and without new/delete? This is impossible AFAIK,
therefore I am currently reorganizing the startup mechanism to make
What are you doing exactly? FYI I am completely reorganizing lyx_gui and
QWork
Am Dienstag, 30. Mai 2006 18:06 schrieb Andre Poenitz:
> Is this a extreme-trial-and-error-ing contest?
No. It is the attempt to find out how to fit QApplication into the GUII
framework in such a way that it does not crash on OS X (and I know what
you will now answer).
> If so, this should be
Georg Baum wrote:
Abdelrazak Younes wrote:
it could be _one_ problem. The static versus pointer code proves that
the same code is translated differently by gcc in linux and windows.
How does it prove that? I suspect that we simply see the code differences
between the windows and linux version
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> This is a static method of FontLoader and I suspect that
Abdelrazak> it needs at least an instantiation of this class.
It does not (because it is static). Anyway there _is_ a global
fontload
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> When do you want to release? I have an idea, but it needs some
Georg> thinking. If it can wait until the weekend I can create a
Georg> patch.
I do not have plans yet. It will not be before next week in any case.
JMarc
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> This is a static method of FontLoader and I suspect that
Abdelrazak> it needs at least an instantiation of this class.
It does not (because it is static). Anyway there _is_ a global
fontloader object, but its constru
Abdelrazak Younes wrote:
> it could be _one_ problem. The static versus pointer code proves that
> the same code is translated differently by gcc in linux and windows.
How does it prove that? I suspect that we simply see the code differences
between the windows and linux version of qt.
Georg
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Georg Baum wrote:
Abdelrazak Younes wrote:
Will commit now.
It would be nice if you could add the comment from your commit log
to the .C file. Otherwise it is easy to get forgotten.
Abdel
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> + Since the QApplication object does so much
Abdelrazak> initialization, it + must be created before any other
Abdelrazak> objects related to the user + interface are created.
Abdelrazak> + Ri
Jean-Marc Lasgouttes wrote:
> Also, could someone tell me what would be a good candidate to fix the
> crash in Mac/qt3 for 1.4? I am lost in this thread.
When do you want to release? I have an idea, but it needs some thinking. If
it can wait until the weekend I can create a patch.
Georg
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Georg Baum wrote:
>> Abdelrazak Younes wrote:
>>> Will commit now.
>> It would be nice if you could add the comment from your commit log
>> to the .C file. Otherwise it is easy to get forgotten.
Abdelrazak> Done.
Al
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> + Since the QApplication object does so much
Abdelrazak> initialization, it + must be created before any other
Abdelrazak> objects related to the user + interface are created.
Abdelrazak> + Right now this is not the c
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Are we really explicitly calling exit()?
Yes, in lyx_gui::exit, which is called in quitLyX. Do you think this
is a problem?
JMarc
On Sat, May 27, 2006 at 04:29:15PM +0200, Georg Baum wrote:
> Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
> > Another idea... Maybe the QApplication destruction is happening too soon
> > in the exit process, this patch remove the QLApplication destructor.
>
> This was the right idea
Andre Poenitz wrote:
-LQApplication::~LQApplication()
-{}
+//LQApplication::~LQApplication()
+//{}
The compiler creates comething identical to this if there is no
destructor defined.
[Which means, that the change as such is good as it removes useless
code, but there should not be any visible d
Andre Poenitz wrote:
- static LQApplication app(argc, argv);
+ static QApplication app(argc, argv);
Why static?
Because it's inside a function (parse_init). It cannot be made a global
variable due to the necessity to pass argc and argv at the construction.
Abdel.
Andre Poenitz wrote:
On Sat, May 27, 2006 at 04:02:33PM +0200, Georg Baum wrote:
Am Samstag, 27. Mai 2006 15:40 schrieb Abdelrazak Younes:
OK, then this patch use a straight QApplication. QLApplication is used
only for Mac as far as I see. And use qApp only.
Does not help:
#0 0xb7b94bcc in Q
On Sat, May 27, 2006 at 03:40:55PM +0200, Abdelrazak Younes wrote:
> Index: lyx_gui.C
> ===
> --- lyx_gui.C (revision 13933)
> +++ lyx_gui.C (working copy)
> @@ -112,7 +112,7 @@
> {
> public:
> LQApplication(int & argc, char **
On Sat, May 27, 2006 at 03:20:36PM +0200, Abdelrazak Younes wrote:
> Georg Baum wrote:
> >Am Freitag, 26. Mai 2006 11:33 schrieb Helge Hafting:
>
> >Abdel, do you have any idea why this happens?
>
> Another idea... Maybe the QApplication destruction is happening too soon
> in the exit process, t
On Sat, May 27, 2006 at 04:02:33PM +0200, Georg Baum wrote:
> Am Samstag, 27. Mai 2006 15:40 schrieb Abdelrazak Younes:
> > OK, then this patch use a straight QApplication. QLApplication is used
> > only for Mac as far as I see. And use qApp only.
>
> Does not help:
>
> #0 0xb7b94bcc in QPixmap
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Jean-Marc Lasgouttes wrote:
>> Could bug 2549 on OS X http://bugzilla.lyx.org/show_bug.cgi?id=2549
>> be related to this?
Georg> I think so. Changing app to a pointer also in qt3 gets also rid
Georg> of the famous "mutex destroy failu
Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Could bug 2549 on OS X
http://bugzilla.lyx.org/show_bug.cgi?id=2549
be related to this?
I think so. Changing app to a pointer also in qt3 gets also rid of the
famous "mutex destroy failure" message.
I think we need to change both qt3 and qt4 in s
Jean-Marc Lasgouttes wrote:
> Could bug 2549 on OS X
> http://bugzilla.lyx.org/show_bug.cgi?id=2549
> be related to this?
I think so. Changing app to a pointer also in qt3 gets also rid of the
famous "mutex destroy failure" message.
I think we need to change both qt3 and qt4 in such a way that t
Jean-Marc Lasgouttes wrote:
"Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Am Freitag, 26. Mai 2006 11:33 schrieb Helge Hafting:
When lyx-qt4 ends, I get: lyx: SIGSEGV signal caught Sorry, you
have found a bug in LyX. Please read the bug-reporting instructions
in Help->Introduction a
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Am Freitag, 26. Mai 2006 11:33 schrieb Helge Hafting:
>> When lyx-qt4 ends, I get: lyx: SIGSEGV signal caught Sorry, you
>> have found a bug in LyX. Please read the bug-reporting instructions
>> in Help->Introduction and send us a bug
Georg Baum wrote:
Abdelrazak Younes wrote:
Will commit now.
It would be nice if you could add the comment from your commit log to the .C
file. Otherwise it is easy to get forgotten.
Done.
Abdel.
Index: lyx_gui.C
===
--- lyx_gu
Georg Baum wrote:
Abdelrazak Younes wrote:
Will commit now.
It would be nice if you could add the comment from your commit log to the .C
file. Otherwise it is easy to get forgotten.
You're right, I'll do that. This reminds me of some feature requests for
SVN:
1) in lyx.cvs list, put an a
Abdelrazak Younes wrote:
> Will commit now.
It would be nice if you could add the comment from your commit log to the .C
file. Otherwise it is easy to get forgotten.
Georg
Abdelrazak Younes wrote:
Reverting to a static QApplication solves the problem. I guess we have
an incompatibility problem between linux and windows!
I think that encapsulating this init code inside a class and make the
QApplication a member of this class should solve the problem.
OK, until
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
This backtrace does not match Edwins report: "atm lyx hangs when
closing the app". That implies that he could run it before, and that
means that parse_init() has been executed already. I would be very
surprised if this proble
Abdelrazak Younes wrote:
Georg Baum wrote:
This backtrace does not match Edwins report: "atm lyx hangs when
closing the app". That implies that he could run it before, and that
means that parse_init() has been executed already. I would be very
surprised if this problem has nothing to do with t
Abdelrazak Younes wrote:
...
I recompiling in debug mode to see where it crash precisely in parse_init.
And of course the full debug version makes mingw gdb crash... I have to
install cygwin.
Will report later.
Abdel.
Georg Baum wrote:
Am Sonntag, 28. Mai 2006 17:01 schrieb Abdelrazak Younes:
Abdelrazak Younes wrote:
Edwin Leuven wrote:
atm lyx hangs when closing the app (qt4, windows)
something to do with this?
Maybe... Just to be sure, try to comment out line 284 in lyx_gui.C:
No, it's not that but som
Georg Baum wrote:
This backtrace does not match Edwins report: "atm lyx hangs when closing
the app". That implies that he could run it before, and that means that
parse_init() has been executed already. I would be very surprised if this
problem has nothing to do with the qApp change.
Edwin, do
Am Sonntag, 28. Mai 2006 17:01 schrieb Abdelrazak Younes:
> Abdelrazak Younes wrote:
> > Edwin Leuven wrote:
> >> atm lyx hangs when closing the app (qt4, windows)
> >>
> >> something to do with this?
> >
> > Maybe... Just to be sure, try to comment out line 284 in lyx_gui.C:
>
> No, it's not tha
Abdelrazak Younes wrote:
Edwin Leuven wrote:
Abdelrazak Younes wrote:
I was maybe a misleaded by the name of the function (start). There is
one QApplication per application so I guess the destruction is
automatic when quitting. But you are probably right. Will commit soon.
atm lyx hangs when
Edwin Leuven wrote:
Abdelrazak Younes wrote:
I was maybe a misleaded by the name of the function (start). There is
one QApplication per application so I guess the destruction is
automatic when quitting. But you are probably right. Will commit soon.
atm lyx hangs when closing the app (qt4, win
Abdelrazak Younes wrote:
I was maybe a misleaded by the name of the function (start). There is
one QApplication per application so I guess the destruction is automatic
when quitting. But you are probably right. Will commit soon.
atm lyx hangs when closing the app (qt4, windows)
something to d
Georg Baum wrote:
Am Samstag, 27. Mai 2006 17:11 schrieb Abdelrazak Younes:
Georg Baum wrote:
+ delete app;
Is this necessary?
I think so. It makes sure that the LQApplication object is destructed at a
defined time. How should the compiler know when to destruct it otherwise?
I was m
Am Samstag, 27. Mai 2006 17:11 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > + delete app;
>
> Is this necessary?
I think so. It makes sure that the LQApplication object is destructed at a
defined time. How should the compiler know when to destruct it otherwise?
Georg
Georg Baum wrote:
Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
Another idea... Maybe the QApplication destruction is happening too soon
in the exit process, this patch remove the QLApplication destructor.
This was the right idea. The 'static' LQApplication changed the
destruction
Georg Baum wrote:
Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
Another idea... Maybe the QApplication destruction is happening too soon
in the exit process, this patch remove the QLApplication destructor.
This was the right idea. The 'static' LQApplication changed the
destruction
Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
> Another idea... Maybe the QApplication destruction is happening too soon
> in the exit process, this patch remove the QLApplication destructor.
This was the right idea. The 'static' LQApplication changed the
destruction order in a way q
Am Samstag, 27. Mai 2006 15:40 schrieb Abdelrazak Younes:
> OK, then this patch use a straight QApplication. QLApplication is used
> only for Mac as far as I see. And use qApp only.
Does not help:
#0 0xb7b94bcc in QPixmapCache::clear () from /usr/lib/libQtGui.so.4
#1 0xb7b4ddb5 in QApplication
Georg Baum wrote:
Am Samstag, 27. Mai 2006 14:57 schrieb Abdelrazak Younes:
I have maybe an idea. Peter Kummel claims the following in his Cmake
patch:
---
and this fixes the crash on exit under windows, maybe
lyx_gui::unregister_
Georg Baum wrote:
Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
Another idea... Maybe the QApplication destruction is happening too soon
in the exit process, this patch remove the QLApplication destructor. I
am not sure this will solve the crash but your backtrace seems to imply
so
Am Samstag, 27. Mai 2006 14:57 schrieb Abdelrazak Younes:
> I have maybe an idea. Peter Kummel claims the following in his Cmake
patch:
>
> ---
> and this fixes the crash on exit under windows, maybe
> lyx_gui::unregister_socket_call
Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
> Another idea... Maybe the QApplication destruction is happening too soon
> in the exit process, this patch remove the QLApplication destructor. I
> am not sure this will solve the crash but your backtrace seems to imply
> so. If not, I
Georg Baum wrote:
Am Freitag, 26. Mai 2006 11:33 schrieb Helge Hafting:
Abdel, do you have any idea why this happens?
Another idea... Maybe the QApplication destruction is happening too soon
in the exit process, this patch remove the QLApplication destructor. I
am not sure this will solve
Georg Baum wrote:
Am Freitag, 26. Mai 2006 11:33 schrieb Helge Hafting:
When lyx-qt4 ends, I get:
lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help->Introduction and send us a bug report, if
necessary. Thanks !
Bye.
Avbrutt (SIGA
Am Freitag, 26. Mai 2006 11:33 schrieb Helge Hafting:
> When lyx-qt4 ends, I get:
> lyx: SIGSEGV signal caught
> Sorry, you have found a bug in LyX. Please read the bug-reporting
> instructions in Help->Introduction and send us a bug report, if
> necessary. Thanks !
> Bye.
> Avbrutt (SIGABRT)
>
Georg Baum wrote:
Helge Hafting wrote:
I could not find any "gmon.out" anywhere, am I supposed to
to more than using --enable-profiling and run make?
gprof documentation seem to suggest that the gmon.out should appear
during the compile, but it didn't.
No, it appears
On Fri, Dec 06, 2002 at 11:04:44AM +, Edwin Leuven wrote:
> On Fri Dec 6, 2002 09:38, Andre Poenitz wrote:
> > Write \parbox{15cm}{...lots of text here...}, mark it and press C-m.
>
> Man that's slow!
:-)
Thanks for the data.
Andre'
--
Those who desire to give up Freedom in order to gai
On Fri Dec 6, 2002 09:38, Andre Poenitz wrote:
> Write \parbox{15cm}{...lots of text here...}, mark it and press C-m.
Man that's slow!
>On load:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls ms/call
On Fri, Dec 06, 2002 at 10:35:28AM +, Edwin Leuven wrote:
> On Fri Dec 6, 2002 07:44, Andre Poenitz wrote:
> > Could you please try the same when all the text is in "math text mode"?
>
> but math text mode doesn't do wrapping and walks of the screen
Write \parbox{15cm}{...lots of text here.
On Fri Dec 6, 2002 07:44, Andre Poenitz wrote:
> Could you please try the same when all the text is in "math text mode"?
but math text mode doesn't do wrapping and walks of the screen
Ed.
On Thu, Dec 05, 2002 at 04:25:02PM +, Edwin Leuven wrote:
> Each sample counts as 0.01 seconds.
> % cumulative self self total
> time seconds secondscalls us/call us/call name
> [..]
> 8.42 0.17 0.08 204250 0.39 0.43 LyXFont::realize(LyX
On Thu, Dec 05, 2002 at 05:02:34PM +, Edwin Leuven wrote:
> I probably didn't follow you. what do you mean with "some oprofiles of just
> the resize" as compared to what I did?
use oprofile instead of gprof
you can't turn gprof on and off when you actually wan
On Thu Dec 5, 2002 15:56, John Levon wrote:
> On Thu, Dec 05, 2002 at 04:44:27PM +, Edwin Leuven wrote:
> > > I'll get some oprofiles of just the resize to see what it tells us
> >
> > how?
>
> don't follow you ...
I probably didn't follow you. what do you mean with "some oprofiles of just
On Thu, Dec 05, 2002 at 04:44:27PM +, Edwin Leuven wrote:
> > I'll get some oprofiles of just the resize to see what it tells us
>
> how?
don't follow you ...
john
--
"Yeah, I woke up in the day accidentally once, the moon was on fire for some
reason and I couldn't see very well and all
> Did you have optimisation enabled ?
LyX 1.3.0cvs of Fri, May 3, 2002
Built on Dec 5 2002, 15:06:10
Configuration
Host type: i686-pc-linux-gnu
Special build flags:warnings assertions
C Compiler: gcc
C Compiler flags: -g
On Thu, Dec 05, 2002 at 04:25:02PM +, Edwin Leuven wrote:
> Compared to xforms qt is slow in resizing. I don't know whether this is
> informative but I compiled both xforms and qt with profiling enabled. Then I
> opened and resized a doc.
Did you have optimisation enabled ?
> time seco
Hi (John?),
Compared to xforms qt is slow in resizing. I don't know whether this is
informative but I compiled both xforms and qt with profiling enabled. Then I
opened and resized a doc.
Output for xforms:
Each sample counts as 0.01 seconds.
% cumulative self self total
On 02-Jul-2001 Lars Gullik Bjønnes wrote:
> It is bad pratice to call the same method again and again when the
> result from the first call just could be reused.
Well but it's cleaner. Anyway I don't care about that it should just
work and as we already agreed we can do that later.
Jür
Juergen Vigna <[EMAIL PROTECTED]> writes:
| On 02-Jul-2001 Jean-Marc Lasgouttes wrote:
|
| > I hope I did not hurt you to much. I'll let you commit this if/when
| > you feel it is necessary.
|
| Well I can do that right away, just let me add some ChangeLog entry.
|
|Jürgen
|
| BTW: I
On 02-Jul-2001 Jean-Marc Lasgouttes wrote:
> I hope I did not hurt you to much. I'll let you commit this if/when
> you feel it is necessary.
Well I can do that right away, just let me add some ChangeLog entry.
Jürgen
BTW: I don't think that we gain a lot in time if we do all that local
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 02-Jul-2001 Jean-Marc Lasgouttes wrote: 100% save #:O)
>> Even when setParagraphData has been called?
Juergen> Ah,...,hmmm, well let's see after we do
[...]
Juergen> On that patched version it should be 100%.
I can agree
On 02-Jul-2001 Jean-Marc Lasgouttes wrote:
> Juergen> 100% save #:O)
>
> Even when setParagraphData has been called?
Ah,...,hmmm, well let's see after we do
diff -u -p -r1.157 insettext.C
--- src/insets/insettext.C 2001/06/29 06:30:52 1.157
+++ src/insets/insettext.C 2001/07/02
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 02-Jul-2001 Jean-Marc Lasgouttes wrote:
>> But how safe is the patch when some lyxtexts get deleted?
Juergen> 100% save #:O)
Even when setParagraphData has been called?
JMarc
On 02-Jul-2001 Jean-Marc Lasgouttes wrote:
> But how safe is the patch when some lyxtexts get deleted?
100% save #:O)
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 02-Jul-2001 Jean-Marc Lasgouttes wrote:
Jean-Marc> I'll try to have a look at whether juergen's patch makes a
Jean-Marc> difference.
>> With Juergen's patch, getLyXText goes down from 13% of total time
>> to 3%.
Juergen> N
Some bits I found out with gprof (with a binary compiled with
lyxstring, but without assertions):
- InsetText::getLyXText use 13% of run time (this is a worst case:
what I do is create a 50x50 table and enter a hundred characters in
it). This would be better if LyXTabular::update was not
> "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
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.
Well it would be nice to have a number otherwise we won't see if it is
map causing the troubles or if it is just the overhead to call a function!
> BTW i
> "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 ti
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> 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 saf
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
> "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 tr
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
g it. We
Juergen> might remove a lot of that function calls.
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.
JMarc
> "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 actu
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 m
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 eno
On 29-Jun-2001 Lars Gullik Bjønnes wrote:
>| For now I would say 1, in the future certainly less that 10. I really
>| doubt that a map will ever be faster than a list or whatever. Further,
>| why do we pass a BufferView* to most insettext methods, whereas most
>| of the times it just calls TEXT(
> "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 ma
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| >>>>> "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
>>>>> "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
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 tw
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
93 matches
Mail list logo
