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'll cc Tommaso and see if he has any
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 thoughts.
>
> Richard
Tommaso is ATM not ve
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 responsive. I am pretty confident,
That I have a pat
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,
and we
> search for
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 method MatchStringAdv::findAux() will b
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
findForwardAdv()
incrementing the cursor
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
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 flushed into debug window at the end?
> P
It may we
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
Am Montag, 11. März 2013 um 12:43:30, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 12:22, Kornel Benko a écrit :
> > 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
> >
Le 11/03/2013 12:22, Kornel Benko a écrit :
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)
I tried the merged manual, and indeed it is very slow. Are you trying
with stdli
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.
Being warned on the plaintext problem, I checked the t
36 matches
Mail list logo
