Le 05/12/2021 à 05:40, sovhist a écrit :
I opended Lyx, hugenote document, scrolled one huge inset up and down, cliced
to other tab and scrolled usual document, after returned to hugenote and
scrolled a bit, if I remember properly.
flame_1 is TextMetrics selected from first hugenote
scrolling an
Hi Valdemaras,
I move this discussion to lyx-devel since you are there too. We have
used the bandwidth of this list long enough with technical issues.
Le 07/12/2021 à 03:19, sovhist a écrit :
Well, I don't see much difference with and without spellcheck. All
"words" are with misspelling marks
4. This isn't related to outline pane. My notes can be huge (to hide parts of
the text temporary) and navigating in such huge notes is painfully slow, CPU
usage rises dramatically (99% of one of the cores of the CPU). Such slowness
presents only when huge note is opened and is visible in L
Le 12/12/2018 à 07:41, Richard Kimberly Heck a écrit :
On 12/12/18 1:41 AM, Richard Kimberly Heck wrote:
My plan is to go ahead and release 2.3.2 for non-Windows platforms as
planned, as this issue does not seem to affect them. If this fix seems
right, then I'll bulid a new Windows installer for
On 12/12/18 1:41 AM, Richard Kimberly Heck wrote:
> Another issue like the one we had with the 2.3.1 release, related to the
> fix for #9158. The commit message explains the issue. The fix seems to
> me to make sense anyway.
>
> The second patch also seems to me to make sense, and it ought to preve
2-1 tarball and a Windows installer built
on it as soon as I'm able.
Comments welcome on that, too.
Riki
>From f7cb4d9500057e5b818e86774a6b463deccd32ff Mon Sep 17 00:00:00 2001
From: Richard Kimberly Heck
Date: Wed, 12 Dec 2018 01:18:16 -0500
Subject: [PATCH] Fix slowness problem repor
On 06/03/2018 01:47 PM, Kornel Benko wrote:
>
> Am Sonntag, 3. Juni 2018 19:29:08 CEST schrieb Jean-Marc Lasgouttes
> :
>
> > Le 03/06/2018 à 18:57, Richard Kimberly Heck a écrit :
>
> > > The server has been all but dead today. I found that the trac database
>
> > > was being scanned from crawl.so
Am Sonntag, 3. Juni 2018 19:29:08 CEST schrieb Jean-Marc Lasgouttes
:
> Le 03/06/2018 à 18:57, Richard Kimberly Heck a écrit :
> > The server has been all but dead today. I found that the trac database
> > was being scanned from crawl.sogou.com, which was apparently ignoring
> > our robots.txt fil
Le 03/06/2018 à 18:57, Richard Kimberly Heck a écrit :
The server has been all but dead today. I found that the trac database
was being scanned from crawl.sogou.com, which was apparently ignoring
our robots.txt file. I've added
Order allow,deny
Allow from all
Deny from crawl.sogou.com
The server has been all but dead today. I found that the trac database
was being scanned from crawl.sogou.com, which was apparently ignoring
our robots.txt file. I've added
Order allow,deny
Allow from all
Deny from crawl.sogou.com
to the httpd configuration for trac, and that seems to have
Le 18/02/2018 à 22:48, jpc a écrit :
commit 9bdfc3ff0d68fb44dcb024016ba4e0415e98e8a2
Author: Pavel Sanda
Date: Sun Feb 18 10:24:19 2018 +0100
* ANNOUNCE - be explicit about slowness.
Sorry, Pavel, seems that I cherry-picked in master a wrong 2.3.x commit.
Reverted.
--
Jean-Pierre
Am 10.01.2017 um 00:24 schrieb Stephan Witt :
>
> Am 08.01.2017 um 19:09 schrieb Jean-Marc Lasgouttes :
>>
>> Le 08/01/2017 à 18:59, Stephan Witt a écrit :
>>> Ok, I don’t see this with current 2.2.x. AFAIK, you did the backport and
>>> applied it there too.
>>> The patch seems to be innocent :)
Am 08.01.2017 um 19:09 schrieb Jean-Marc Lasgouttes :
>
> Le 08/01/2017 à 18:59, Stephan Witt a écrit :
>> Ok, I don’t see this with current 2.2.x. AFAIK, you did the backport and
>> applied it there too.
>> The patch seems to be innocent :)
>
> A bisect would be appreciated :) Note that I have
On 01/08/2017 05:22 PM, Enrico Forestieri wrote:
> On Sun, Jan 08, 2017 at 03:14:51PM -0500, Richard Heck wrote:
>> On 01/08/2017 02:05 PM, Enrico Forestieri wrote:
>>> On Sun, Jan 08, 2017 at 01:45:57PM -0500, Richard Heck wrote:
>>>
On 01/08/2017 09:17 AM, Scott Kostyshak wrote:
> On Sun
On Sun, Jan 08, 2017 at 03:14:51PM -0500, Richard Heck wrote:
> On 01/08/2017 02:05 PM, Enrico Forestieri wrote:
> > On Sun, Jan 08, 2017 at 01:45:57PM -0500, Richard Heck wrote:
> >
> >> On 01/08/2017 09:17 AM, Scott Kostyshak wrote:
> >>> On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chré
On 01/08/2017 02:05 PM, Enrico Forestieri wrote:
> On Sun, Jan 08, 2017 at 01:45:57PM -0500, Richard Heck wrote:
>
>> On 01/08/2017 09:17 AM, Scott Kostyshak wrote:
>>> On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chrétien wrote:
>>>
The only thing I noticed is a
lot of messages
On Sun, Jan 08, 2017 at 01:45:57PM -0500, Richard Heck wrote:
> On 01/08/2017 09:17 AM, Scott Kostyshak wrote:
> > On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chrétien wrote:
> >
> >> The only thing I noticed is a
> >> lot of messages
> >>
> >> QFile::remove: Empty or null file name
> >>
On 01/08/2017 09:17 AM, Scott Kostyshak wrote:
> On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chrétien wrote:
>
>> The only thing I noticed is a
>> lot of messages
>>
>> QFile::remove: Empty or null file name
>>
>> in the calling shell window.
> We noticed the same thing at
> https://www.m
Le 08/01/2017 à 18:59, Stephan Witt a écrit :
Ok, I don’t see this with current 2.2.x. AFAIK, you did the backport and
applied it there too.
The patch seems to be innocent :)
A bisect would be appreciated :) Note that I have noticed problems with
math previews not updating in master, I do not
Am 08.01.2017 um 18:42 schrieb Jean-Marc Lasgouttes :
>
> Le 08/01/2017 à 18:00, Stephan Witt a écrit :
>> I tried the current master (commit 21259b66b5d36913aaf4dcded8aaac3254b04354)
>> on Mac.
>> It seems to be fast with Qt5 - but I’m not sure how to verify that.
>>
>> One thing I’ve noticed:
Le 08/01/2017 à 18:00, Stephan Witt a écrit :
I tried the current master (commit 21259b66b5d36913aaf4dcded8aaac3254b04354) on
Mac.
It seems to be fast with Qt5 - but I’m not sure how to verify that.
One thing I’ve noticed: the images in text are not shown immediately when
scrolling
through the
Am 31.12.2016 um 13:16 schrieb Jean-Marc Lasgouttes :
>
> Le 16/12/2016 à 16:42, Jean-Marc Lasgouttes a écrit :
>> I'd be interested to see other tests, especially on MacOS and Windows.
>
> Since there not much testing going on, I pushed the patch to master :)
> Notable differences are:
> * the
On Sun, Jan 08, 2017 at 09:30:32AM +, Jean-Pierre Chrétien wrote:
> The only thing I noticed is a
> lot of messages
>
> QFile::remove: Empty or null file name
>
> in the calling shell window.
We noticed the same thing at
https://www.mail-archive.com/search?l=mid&q=a15e9a60-11bb-c081-84cb-9b
Le 07/01/2017 à 02:05, Richard Heck a écrit :
We (specifically, Jean-Marc Lasgouttes) have recently made some changes
to the text rendering algorithms in LyX. We would appreciate it if those
who are able could compile and use the 2.2.x branch of the git
repository, so that these changes can recei
We (specifically, Jean-Marc Lasgouttes) have recently made some changes
to the text rendering algorithms in LyX. We would appreciate it if those
who are able could compile and use the 2.2.x branch of the git
repository, so that these changes can receive sufficient testing before
we schedule the rel
Le 06/01/2017 à 20:16, Richard Heck a écrit :
OK, go ahead and commit then. I will send a note to lyx-devel and
lyx-users announcing that this has happened and encouraging people, as
they are able, to use 2.2.x.
It is in.
JMarc
On 01/06/2017 10:17 AM, Jean-Marc Lasgouttes wrote:
> Le 06/01/2017 à 16:13, Richard Heck a écrit :
>> I guess I'd be inclined to go
>> ahead and commit it, then. Maybe we can just encourage as many people as
>> possible to use the 2.2.x branch (if they're not already using master),
>> so it gets t
r some action on
the latter, looking towards a 2.2.3 release maybe around the end of the
month. This could be delayed a bit, if need be, and I guess this
slowness has been a problem for some people, so it would be good if we
could improve the situation for 2.2.3. I guess I'd be inclined to
Le 06/01/2017 à 16:13, Richard Heck a écrit :
I guess I'd be inclined to go
ahead and commit it, then. Maybe we can just encourage as many people as
possible to use the 2.2.x branch (if they're not already using master),
so it gets tested.
I would agree with that.
One question: Do you want to
Le 31/12/2016 à 15:26, Jean-Marc Lasgouttes a écrit :
Le 31/12/2016 à 15:24, Jean-Marc Lasgouttes a écrit :
It is this particular patch. I amended it since the initial July 5
creattion, but apparently git does not update date by default.
To be more precise, this is the commit below, pushed on
On Sat, Dec 31, 2016 at 05:36:47PM +0100, Jean-Marc Lasgouttes wrote:
> Le 31/12/2016 à 17:34, Kornel Benko a écrit :
> > > commit c5119c97fcf84e8dd2cfcdd605cc0a9ffa8b5bc4
> > > Author: Jean-Marc Lasgouttes
> > > Date: Tue Jul 5 14:06:22 2016 +0200
> > >
> > > Add caching for the QTextLayo
Le 31/12/2016 à 17:34, Kornel Benko a écrit :
commit c5119c97fcf84e8dd2cfcdd605cc0a9ffa8b5bc4
Author: Jean-Marc Lasgouttes
Date: Tue Jul 5 14:06:22 2016 +0200
Add caching for the QTextLayout objects we use
I see. Yes, that was what I have seen, not realizing when it was pushed.
Does
Am Samstag, 31. Dezember 2016 um 15:26:47, schrieb Jean-Marc Lasgouttes
> Le 31/12/2016 à 15:24, Jean-Marc Lasgouttes a écrit :
> > It is this particular patch. I amended it since the initial July 5
> > creattion, but apparently git does not update date by default.
>
> To be more precise, this i
Le 31/12/2016 à 15:24, Jean-Marc Lasgouttes a écrit :
It is this particular patch. I amended it since the initial July 5
creattion, but apparently git does not update date by default.
To be more precise, this is the commit below, pushed on Dec 19. I have
prepared a version for stable (for disc
Le 31/12/2016 à 13:26, Kornel Benko a écrit :
Am Samstag, 31. Dezember 2016 um 13:16:41, schrieb Jean-Marc Lasgouttes
Le 16/12/2016 à 16:42, Jean-Marc Lasgouttes a écrit :
I'd be interested to see other tests, especially on MacOS and Windows.
Since there not much testing going on, I pushed
Am Samstag, 31. Dezember 2016 um 13:16:41, schrieb Jean-Marc Lasgouttes
> Le 16/12/2016 à 16:42, Jean-Marc Lasgouttes a écrit :
> > I'd be interested to see other tests, especially on MacOS and Windows.
>
> Since there not much testing going on, I pushed the patch to master :)
When? I do not s
Le 16/12/2016 à 16:42, Jean-Marc Lasgouttes a écrit :
I'd be interested to see other tests, especially on MacOS and Windows.
Since there not much testing going on, I pushed the patch to master :)
Notable differences are:
* the caching of getLayout is disabled with Qt5
* the profiling hooks ar
Le 09/12/2016 à 15:58, Jean-Marc Lasgouttes a écrit :
Le 07/12/2016 à 16:10, Jean-Marc Lasgouttes a écrit :
Le 07/12/2016 à 12:15, Jean-Marc Lasgouttes a écrit :
I'll post a new version to try soon.
Here is a patch to play with. It is not perfect, but I would be
interested to know whether it
Le 07/12/2016 à 16:10, Jean-Marc Lasgouttes a écrit :
Le 07/12/2016 à 12:15, Jean-Marc Lasgouttes a écrit :
I'll post a new version to try soon.
Here is a patch to play with. It is not perfect, but I would be
interested to know whether it improves performance with Qt4.
I have improved a bit
Le 09/12/2016 à 15:37, Tommaso Cucinotta a écrit :
On 09/12/2016 11:34, Jean-Marc Lasgouttes wrote:
Note though
that with my patch we directly draw the cached QTextLayout object.
your patch turns LyX from a snail to a lightning fast editor :-)!
It's a long time I don't have memory of being ab
On 09/12/2016 11:34, Jean-Marc Lasgouttes wrote:
Note though
that with my patch we directly draw the cached QTextLayout object.
your patch turns LyX from a snail to a lightning fast editor :-)!
It's a long time I don't have memory of being able to go through a doc at such
a speed, just keepin
Le 08/12/2016 à 23:18, Tommaso Cucinotta a écrit :
likely with this sequel [1], so the innermost LyX code seems:
lyx::frontend::GuiFontMetrics::breakAt,lyx::Row::Element::breakAt,
lyx::Row::shortenIfNeeded,lyx::TextMetrics::breakRow,lyx::TextMetrics::redoParagraph,
breakAt is the main method f
In case it might help, this seems a recurrent stack trace during the slowness
writev,??,??,xcb_writev,_XSend,XRenderAddGlyphs,QFontEngineX11FT::uploadGlyphToServer(QFontEngineFT::QGlyphSet*,,
QFontEngineFT::loadGlyph(QFontEngineFT::QGlyphSet*,,QFontEngineFT::recalcAdvances(QGlyphLayout
Le 08/12/2016 à 16:07, Jean-Marc Lasgouttes a écrit :
Also, it would be nice to know what are the callers of freettype that
consume the most time.
As a reminder here is where I got last time with kcachegrind:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg194401.html
The caching in Q
Le 08/12/2016 à 16:01, Tommaso Cucinotta a écrit :
On 08/12/2016 14:39, Jean-Marc Lasgouttes wrote:
On my ubuntu 12.40 station I get:
Xft.dpi:96
Xft.antialias:1
Xft.hinting:1
Xft.hintstyle:hintslight
Xft.rgba:none
Xft.lcdfilter:none
mine:
Did you try the patch I post
On 08/12/2016 14:39, Jean-Marc Lasgouttes wrote:
On my ubuntu 12.40 station I get:
Xft.dpi:96
Xft.antialias:1
Xft.hinting:1
Xft.hintstyle:hintslight
Xft.rgba:none
Xft.lcdfilter:none
mine:
tommaso@tommylap:~/lyx-trunk-ws/lyx$ xrdb -query |grep Xft
Xft.antialias: 1
Xft.
Le 08/12/2016 à 14:29, Jean-Marc Lasgouttes a écrit :
Le 08/12/2016 à 12:36, Tommaso Cucinotta a écrit :
On 08/12/2016 11:09, Tommaso Cucinotta wrote:
I'm now trying oprofile/operf, just to compare output.
that's quite similar
How do we know what are the freetype settings in effect (anitali
Le 08/12/2016 à 12:36, Tommaso Cucinotta a écrit :
On 08/12/2016 11:09, Tommaso Cucinotta wrote:
I'm now trying oprofile/operf, just to compare output.
that's quite similar
How do we know what are the freetype settings in effect (anitalisaing,
hinting, ...)?
JMarc
On 08/12/2016 11:09, Tommaso Cucinotta wrote:
I'm now trying oprofile/operf, just to compare output.
that's quite similar
CPU_CLK_UNHALT...|
samples| %|
--
1873080 100.000 lyx
CPU_CLK_UNHALT...|
samples| %|
--
16
On 08/12/2016 04:49, Richard Heck wrote:
I could do a valgrind thing of the same sort if you tell me what command
to run.
it's quite straightforward:
valgrind --tool=callgrind /usr/bin/lyx
# play with lyx, especially open a doc with a full page of text, move cursor
on it, select parts wit
th what screen fonts are being
>> used?
>
> The recompiled & Qt 4.8.7-linked version, with -g enabled (master):
>
> http://retis.sssup.it/~tommaso/callgrind.out.10301.gz
>
> slowness seems there, changed screen font to a different one, slowness
> still there, e.g., whe
h -g enabled (master):
http://retis.sssup.it/~tommaso/callgrind.out.10301.gz
slowness seems there, changed screen font to a different one, slowness still
there, e.g., when keeping a key pressed, but especially when selecting with
shift+cursor ...
T.
On 12/07/2016 04:44 PM, Tommaso Cucinotta wrote:
> On 06/12/2016 23:12, Tommaso Cucinotta wrote:
>> I'll try to profile later, unless others made progress on this already.
>
> valgrind --tool=callgrind reports, without recompiling with -g, the
> following:
>
> libfreetype.so.6.12.377.14%
> libQ
On 07/12/2016 18:58, Richard Heck wrote:
- why is the slowness visible on Ubuntu 16.10 (Qt 4.8.7) but not
Ubuntu 12.04 (Qt 4.8.1)?
I'm having the issue on Ubuntu 16.10 with Qt 4.8.7.
tommaso@tommylap:~/lyx-trunk-ws/lyx$ dpkg -l | grep libqt4 | grep -v 386
ii libqt4-dbus:
On 06/12/2016 23:12, Tommaso Cucinotta wrote:
I'll try to profile later, unless others made progress on this already.
valgrind --tool=callgrind reports, without recompiling with -g, the following:
libfreetype.so.6.12.3 77.14%
libQtGui.so.4.8.7 8.10%
...
~46 million calls to smth in l
On 12/07/2016 06:15 AM, Jean-Marc Lasgouttes wrote:
>
> - why is the slowness visible on Ubuntu 16.10 (Qt 4.8.7) but not
> Ubuntu 12.04 (Qt 4.8.1)?
And more weirdly: I have never seen this kind of problem on Fedora with
Qt 4.8.7.
Richard
Le 07/12/2016 à 12:15, Jean-Marc Lasgouttes a écrit :
I'll post a new version to try soon.
Here is a patch to play with. It is not perfect, but I would be
interested to know whether it improves performance with Qt4.
JMarc
From 186d439af023942a6171a6a8ce5bafaa2c6715e0 Mon Sep 17 00:00:00 200
which lyx` | grep -i qt
libQtGui.so.4 => /usr/lib/x86_64-linux-gnu/libQtGui.so.4
(0x7fb5a7544000)
libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4
(0x7fb5a7052000)
Also, forgot to mention that in the recompiled from master I don't see
the slowness,
but that'
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
(0x7fb5a7544000)
libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4
(0x7fb5a7052000)
Also, forgot to mention that in the recompiled from master I don't see the
slowness,
but that's recompiled with Qt5.
The only thing I
On Tue, Dec 06, 2016 at 11:12:56PM +0100, Tommaso Cucinotta wrote:
> Hi there,
>
> I just used LyX 2.2 (from Ubuntu) today to take some notes, and noticed also
> this terrible slowness on a very small document, without any pane open, just
> showing up while typing up to a ~3-4
Hi there,
I just used LyX 2.2 (from Ubuntu) today to take some notes, and noticed also
this terrible slowness on a very small document, without any pane open, just
showing up while typing up to a ~3-4 lines paragraph without breaks, with the
slowness also just for moving cursor, to the point
actly do you see the slow part? (when copying, when
> > pasting?) I do not see slowness, but I think it's because I
> > misunderstood. Please do this in a separate email to lyx-devel so we can
> > separate the conversations.
> >
>
> 1. new document
> 2. output font s
actly do you see the slow part? (when copying, when
> > pasting?) I do not see slowness, but I think it's because I
> > misunderstood. Please do this in a separate email to lyx-devel so we can
> > separate the conversations.
> >
>
> 1. new document
> 2. output font s
ing a lot. There seems to be a problem
>> handling this (script or unicode or whatnot).
>
> Good to know. Can you give some enumerated simple steps to reproduce?
> And where exactly do you see the slow part? (when copying, when
> pasting?) I do not see slowness, but I think it's be
2.1.4 works fine. I am not sure this is just the CPU load because
there is "only" a 10 percent difference (50 vs. 40 %).
Sorry, my mistake. I had the complete source preview open somewhere. I
guess that explains the slowness...
Daniel
Le 29/08/2016 à 12:04, racoon a écrit :
LyX 2.2 is very slow compared to LyX 2.1.4 (on Windows). (I have only a
meager dual core processor though.)
For example, if I open a long document like the Users Guide and make a
text selection bigger or smaller 2.2 stutters a lot (up to not reacting)
whil
LyX 2.2 is very slow compared to LyX 2.1.4 (on Windows). (I have only a
meager dual core processor though.)
For example, if I open a long document like the Users Guide and make a
text selection bigger or smaller 2.2 stutters a lot (up to not reacting)
while 2.1.4 works fine. I am not sure this
On 03/04/13 22:29, Kornel Benko wrote:
> Am Mittwoch, 3. April 2013 um 20:32:22, schrieb Tommaso Cucinotta
>
>> I can run all of the findadv tests to check whether the patch broke anything.
>> That's even easier than entering with my head back into that spaghetti code
>> :-).
>
> I run them, an
Am Mittwoch, 3. April 2013 um 20:32:22, schrieb Tommaso Cucinotta
> On 31/03/13 12:38, Kornel Benko wrote:
> > Tommaso is ATM not very responsive. I am pretty confident,
> > That I have a patch, which does not affect any other parts
> > of advanced search.
>
> Hi,
>
> I can run all of the finda
On 31/03/13 12:38, Kornel Benko wrote:
> Tommaso is ATM not very responsive. I am pretty confident,
> That I have a patch, which does not affect any other parts
> of advanced search.
Hi,
I can run all of the findadv tests to check whether the patch broke anything.
That's even easier than entering
On 11/03/13 11:22, Kornel Benko wrote:
> Hi,
>
> advanced search in my document (for a non-existent string on all opened
> documents):
> takes 227 seconds. Moreover, at the end of search (dialog asking to start
> over)
> eats so much memory ( > 4GB), that my computer starts to using swap disk.
Am Sonntag, 31. März 2013 um 11:07:36, schrieb Richard Heck
>
> Oh, never mind, I remember it now. It looked fine to me.
>
> rh
Committed slightly modified version.
Kornel
signature.asc
Description: This is a digitally signed message part.
On 03/31/2013 11:07 AM, Richard Heck wrote:
On 03/31/2013 07:38 AM, Kornel Benko wrote:
Am Dienstag, 19. März 2013 um 09:08:49, schrieb Richard Heck
> > This patch removes the slowness for me.
> >
> > OK to commit?
> >
>
> I don't know this code. I&
On 03/31/2013 07:38 AM, Kornel Benko wrote:
Am Dienstag, 19. März 2013 um 09:08:49, schrieb Richard Heck
> > This patch removes the slowness for me.
> >
> > OK to commit?
> >
>
> I don't know this code. I'll cc Tommaso and see if he has any tho
Am Dienstag, 19. März 2013 um 09:08:49, schrieb Richard Heck
> > This patch removes the slowness for me.
> >
> > OK to commit?
> >
>
> I don't know this code. I'll cc Tommaso and see if he has any thoughts.
>
> Richard
Tommaso is ATM not very re
On 03/19/2013 06:17 AM, Kornel Benko wrote:
Am Montag, 18. März 2013 um 14:01:44, schrieb Kornel Benko
> The slowness in normal search part happens, because we have very
inefficient
> algorithm.
> Suppose we have a string "This is a string." at the cursor position,
Am Montag, 18. März 2013 um 14:01:44, schrieb Kornel Benko
> The slowness in normal search part happens, because we have very inefficient
> algorithm.
> Suppose we have a string "This is a string." at the cursor position, and we
> search for "abcd".
>
> The
The slowness in normal search part happens, because we have very inefficient
algorithm.
Suppose we have a string "This is a string." at the cursor position, and we
search for "abcd".
The method MatchStringAdv::findAux() will be called now successively from
findForwardAd
On 03/13/2013 05:55 AM, Kornel Benko wrote:
Am Dienstag, 12. März 2013 um 17:09:33, schrieb Pavel Sanda
> Kornel Benko wrote:
> > Than I tried lyx, as I most of the time use.
> > 1.) with own userdir
> > 2.) with some debug output.
> > MEMORY use!!!
>
> Isn't it only debug output flush
eding
UserGuide 110 MB
Additional 112 MB
Embedded113 MB
Math119 MB
Customization 121 MB
--. End 126 MB
Apart from the slowness, no farther problems.
Kornel
signa
Kornel Benko wrote:
> Than I tried lyx, as I most of the time use.
> 1.) with own userdir
> 2.) with some debug output.
> MEMORY use!!!
Isn't it only debug output flushed into debug window at the end?
P
Am Dienstag, 12. März 2013 um 15:08:54, schrieb Richard Heck
> JMarc's post showed some heavy memory consumption in the BibTeX parser.
> I wasn't able to get any kind of hit when I put a breakpoint into
> InsetBibtex::parseBibTeX(). But maybe your file is different from any I
> tried. Can you s
Am Dienstag, 12. März 2013 um 15:08:54, schrieb Richard Heck
> On 03/12/2013 02:09 PM, Kornel Benko wrote:
> >
> > Am Dienstag, 12. März 2013 um 18:57:06, schrieb Kornel Benko
> >
> >
> > >
> >
> > > In order to measure the time, I have a konsole-window with "date"
> >
> > > Start the advaced se
On 03/12/2013 02:09 PM, Kornel Benko wrote:
Am Dienstag, 12. März 2013 um 18:57:06, schrieb Kornel Benko
>
> In order to measure the time, I have a konsole-window with "date"
> Start the advaced search.
> As soon, as the search ends, e.g. the expected dialog displays,
> I get the focus t
Am Dienstag, 12. März 2013 um 18:57:06, schrieb Kornel Benko
>
> In order to measure the time, I have a konsole-window with "date"
> Start the advaced search.
> As soon, as the search ends, e.g. the expected dialog displays,
> I get the focus to the konsole, insert
> From now on, the memory usag
Am Dienstag, 12. März 2013 um 13:08:32, schrieb Richard Heck
> On 03/11/2013 02:41 PM, Kornel Benko wrote:
> >
> > Am Montag, 11. März 2013 um 14:23:59, schrieb Richard Heck
> >
> >
> > > On 03/11/2013 12:46 PM, Kornel Benko wrote:
> >
> > > >
> >
> > ...
> >
> > > >
> >
> > > > add InsetBibtex:
On 03/11/2013 02:41 PM, Kornel Benko wrote:
Am Montag, 11. März 2013 um 14:23:59, schrieb Richard Heck
> On 03/11/2013 12:46 PM, Kornel Benko wrote:
> >
...
> >
> > add InsetBibtex::plaintext() again.
> >
> Can you post a backtrace showing where that is being called from? I
> don't kn
Here is a streamlined version of the massif file that Kornel sent
privately to me. As far as I can see below, it only accounts for 50 to
100MB.
Comments in the output below (I replaced ugle basic_string<> expressions
with docstring).
JMarc
The memory is actually increasing and the largest s
On 03/11/2013 02:41 PM, Kornel Benko wrote:
Am Montag, 11. März 2013 um 14:23:59, schrieb Richard Heck
> On 03/11/2013 12:46 PM, Kornel Benko wrote:
> >
...
> >
> > add InsetBibtex::plaintext() again.
> >
> Can you post a backtrace showing where that is being called from? I
> don't kn
Le 11/03/13 19:33, Kornel Benko a écrit :
Am Montag, 11. März 2013 um 17:46:50, schrieb Kornel Benko
I tried, but got only this output with
#valgrind --tool=massif ...
==21508== Massif, a heap profiler
==21508== Copyright (C) 2003-2011, and GNU GPL'd, by Nicholas Nethercote
==21508== Using
Am Montag, 11. März 2013 um 19:28:47, schrieb Jean-Marc Lasgouttes
>
> Kornel Benko a écrit :
> >Interested in the valgrind output (267 kb)?
>
>
> Sure.
Aaah. I incidentally replaced it with output of 'valgrind --tool=massif'
But will make a new one. Tomorrow, OK?
> JMarc
Kornel
s
Am Montag, 11. März 2013 um 14:23:59, schrieb Richard Heck
> On 03/11/2013 12:46 PM, Kornel Benko wrote:
> >
...
> >
> > add InsetBibtex::plaintext() again.
> >
> Can you post a backtrace showing where that is being called from? I
> don't know what advanced search is doing exactly, but I know it
Kornel Benko a écrit :
>Interested in the valgrind output (267 kb)?
Sure.
JMarc
Am Montag, 11. März 2013 um 17:46:50, schrieb Kornel Benko
> > Another possibility is to use the 'massif' tool of valgrind. It will
> > tell you where the data is allocated.
>
> I will try this one also.
>
I tried, but got only this output with
#valgrind --tool=massif ...
==21508== M
On 03/11/2013 12:46 PM, Kornel Benko wrote:
Am Montag, 11. März 2013 um 15:33:36, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 14:42, Kornel Benko a écrit :
> > ==11211== LEAK SUMMARY:
> > ==11211== definitely lost: 33,700 bytes in 189 blocks
> > ==11211== indirectly lost: 59,454 bytes in
Am Montag, 11. März 2013 um 15:33:36, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 14:42, Kornel Benko a écrit :
> > ==11211== LEAK SUMMARY:
> > ==11211== definitely lost: 33,700 bytes in 189 blocks
> > ==11211== indirectly lost: 59,454 bytes in 1,606 blocks
> > ==11211== possibly lost: 15,783 by
Am Montag, 11. März 2013 um 15:41:06, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 13:42, Kornel Benko a écrit :
> > > I tried the merged manual, and indeed it is very slow. Are you trying
> > > with stdlib-debug on?
> >
> > I don't think so. How can I check?
> >
> > In cmake I am creating a de
Le 11/03/2013 13:42, Kornel Benko a écrit :
> I tried the merged manual, and indeed it is very slow. Are you trying
> with stdlib-debug on?
I don't think so. How can I check?
In cmake I am creating a debug version, but without using LYX_STDLIB_DEBUG.
This means, the gcc does *not* have
-D_G
Le 11/03/2013 14:42, Kornel Benko a écrit :
==11211== LEAK SUMMARY:
==11211== definitely lost: 33,700 bytes in 189 blocks
==11211== indirectly lost: 59,454 bytes in 1,606 blocks
==11211== possibly lost: 15,783 bytes in 59 blocks
==11211== still reachable: 1,721,311 bytes in 8,392 blocks
==11211==
Am Montag, 11. März 2013 um 13:42:34, schrieb Kornel Benko
>
> Trying... takes nearly forever ... only 1 of my 4 cpu's is busy (100%) ...
>
> will mail again, when (and if?) the seach under valgrind ends.
>
> > JMarc
So, search finished, no visible memory lost.
The dialog
Opened files
1 - 100 of 546 matches
Mail list logo
