Georg Baum wrote:
Abdelrazak Younes wrote:
I agree that we need two comparison methods. I am not sure though that
the operator==() should be lighter one. I 'd rather look at the all the
cases where it is used and replace them on a case by case with
equivalent() or isSimilarTo() as I suggeste
Abdelrazak Younes wrote:
> I agree that we need two comparison methods. I am not sure though that
> the operator==() should be lighter one. I 'd rather look at the all the
> cases where it is used and replace them on a case by case with
> equivalent() or isSimilarTo() as I suggested earlier. I fea
Andre Poenitz wrote:
On Tue, Mar 24, 2009 at 08:02:12AM -0400, rgheck wrote:
I had a similar concern. Just changing the semantics of operator== seems
dangerous. But another option would be, short term, to replace it by two
methods, get things working again, and then make one of them back i
On Tue, Mar 24, 2009 at 08:02:12AM -0400, rgheck wrote:
> I had a similar concern. Just changing the semantics of operator== seems
> dangerous. But another option would be, short term, to replace it by two
> methods, get things working again, and then make one of them back into
> operator==.
Abdelrazak Younes wrote:
Hi Georg,
Georg Baum wrote:
Even if you ignore the InsetInclude problem for a moment, there will
be more
performance problems caused by the current FileName implementation. The
reason is simple: FileName once was a lightweight wrapper around a
string,
and it is still
Hi Georg,
Georg Baum wrote:
Even if you ignore the InsetInclude problem for a moment, there will be more
performance problems caused by the current FileName implementation. The
reason is simple: FileName once was a lightweight wrapper around a string,
and it is still used in many places like tha
Vincent van Ravesteijn - TNW wrote:
>>Yes, that is the case I am aware of. I just tried, and the patch
> ensures
>>that you cannot open two buffers in that case. Note that there is still
>>a bug in setting path.d->name in FileName::onlyPath(), this needs to be
>>set from path.d->fi, not d->fi.
>
>> I could be wrong, but I think so, yes. The problem is that an
absolute
>> filename isn't the same as a canonical filename, i.e., one with
>> symlinks etc resolved. We don't want to open /home/me/file.lyx and
>> /tmp/file.lyx in different buffers if, in fact, they are the same
file.
>
>Yes, th
rgheck wrote:
> Georg Baum wrote:
>> rgheck wrote:
>>
>>> Unfortunately, the case where equivalence() is needed is one of the
>>> cases causing the performance problems.
>>>
>>
>> Honest question: Really?
>>
>>
> I could be wrong, but I think so, yes. The problem is that an absolute
> file
On Sun, Mar 22, 2009 at 01:48:39PM +0100, Georg Baum wrote:
> Apart from the performance changes, the patch corrects the following issues:
I can confirm that this patch solves the slowness problem with child
documents (I only checked it on Solaris). Well spotted Georg!
--
Enrico
Georg Baum wrote:
rgheck wrote:
Georg Baum wrote:
I believe that the performance problems could be solved quite easily by
basing FileName::operator==() on simple string comparison again and
implenting an equivalence() method that is used only when needed.
Unfortunately, the
rgheck wrote:
> Georg Baum wrote:
>> I believe that the performance problems could be solved quite easily by
>> basing FileName::operator==() on simple string comparison again and
>> implenting an equivalence() method that is used only when needed.
>>
>>
> Unfortunately, the case where equivale
Georg Baum wrote:
I believe that the performance problems could be solved quite easily by
basing FileName::operator==() on simple string comparison again and
implenting an equivalence() method that is used only when needed.
Unfortunately, the case where equivalence() is needed is one of the
Vincent van Ravesteijn - TNW wrote:
>>> Do we need a new class that we use internally. In this class we store
>
>>> a filename, which is case-sensitive on case-sensitive filesystem,
> that
>>> is guaranteed to be a long filename and not a short one (on Windows),
>
>>> that is not a symlink, that
Helge Hafting wrote:
rgheck wrote:
Vincent van Ravesteijn - TNW wrote:
Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, t
>Seems excessive indeed. Ideally, typing text should be fine
>even with a "sleep(1)" in every filesystem interface. Just a
>slight stop whenever the emergency save happens.
That's why I now use a test document that I access via WebDav. It is
very rewarding to see the speed up then.
>Helge Hafti
rgheck wrote:
Vincent van Ravesteijn - TNW wrote:
Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, that is
guaranteed to b
Hi all,
I'm not familar with the coding of LyX in any case - and so don't misinterpret
my comment as any kind of paternalism. LyX is a worthy successor of SciWord,
open source, and full of excellent ideas and work.
I have the same suspicion as Vincent: Each user input inside the master(not
onl
>> Do we need a new class that we use internally. In this class we store
>> a filename, which is case-sensitive on case-sensitive filesystem,
that
>> is guaranteed to be a long filename and not a short one (on Windows),
>> that is not a symlink, that is relative or absolute (pick one or
both).
>
Vincent van Ravesteijn - TNW wrote:
Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, that is
guaranteed to be a long file
> Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, that is
guaranteed to be a long filename and not a short one (on Windows), that
The previous == and != checks had just been against the file NAMES,
which meant you could get file1 != file2, >if the names were symlinks
pointing to the same file, and names with different capatalizations
would be seen >as different on Windows, VFAT, etc. So Abdel changed it
to call QFileInfo::
-Original Message-
From: rgheck [mailto:rgh...@bobjweil.com]
Sent: donderdag 19 maart 2009 20:46
To: Vincent van Ravesteijn - TNW
Cc: lyx-devel@lists.lyx.org
Subject: Re: LyX 1.6.2: possible performance issue inside master
document
Vincent van Ravesteijn - TNW wrote:
>
>
Vincent van Ravesteijn - TNW wrote:
So, if there are four filesystem-checks in Linux, there are at least
six on Windows and maybe the compiler does something smart when
os::internal_path does nothing.
That would make it worse. But enough worse that I see nothing
here? Is networ
Vincent van Ravesteijn - TNW wrote:
rgheck wrote:
By the way, can you remember what problem Bennet had which made you
adding the lhs.refresh() and rhs.refresh() lines to
FileName::operator==(). This solution looks a bit like "Abdel's
hammer".
Not right now, no, thou
>> So, if there are four filesystem-checks in Linux, there are at least
>> six on Windows and maybe the compiler does something smart when
>> os::internal_path does nothing.
>>
>>
>That would make it worse. But enough worse that I see nothing
>here? Is network file system performance much >s
rgheck wrote:
>>> By the way, can you remember what problem Bennet had which made you
>>> adding the lhs.refresh() and rhs.refresh() lines to
>>> FileName::operator==(). This solution looks a bit like "Abdel's
hammer".
>>>
>>>
>> Not right now, no, though it's probably on the list somewhere.
rgheck wrote:
By the way, can you remember what problem Bennet had which made you
adding the lhs.refresh() and rhs.refresh() lines to
FileName::operator==(). This solution looks a bit like "Abdel's hammer".
Not right now, no, though it's probably on the list somewhere. But I
think the proble
Vincent van Ravesteijn - TNW wrote:
As a data point, I don't see any slowdown in Linux, using latest
branch and Qt 4.4.3, under Fedora 8. UNLESS I open the View Source
window, when (unsurprisingly) I do. Same result if I put the files
on a network drive.
Is it possible that LaTeX is being genera
>As a data point, I don't see any slowdown in Linux, using latest
>branch and Qt 4.4.3, under Fedora 8. UNLESS I open the View Source
>window, when (unsurprisingly) I do. Same result if I put the files
>on a network drive.
>
>Is it possible that LaTeX is being generated, even though the window
>
Well list didn't accept the large files. Now with small ones. Slowness is the
same.
Thanks,
Zardoz
Original-Nachricht
> Datum: Thu, 19 Mar 2009 12:31:59 -0400
> Von: rgheck
> An: pseudo2...@gmx.at
> CC: lyx-devel@lists.lyx.org
> Betreff: Re: LyX 1.6.2: p
pseudo2...@gmx.at wrote:
Well, my attached zip-file has been rejected. I try the lyx-files.
An no, the latex "view source" window is not open.
OK, thanks.
As a data point, I don't see any slowdown in Linux, using latest branch
and Qt 4.4.3, under Fedora 8. UNLESS I open the View Source wi
pseudo2...@gmx.at wrote:
I've created some testdocument that reproduces the behaviour (where can files be uploaded?).
Just attach it.
rh
> If you are able to send me a test document (maybe privately) I'll have a
> look. Even better: put it in a new bugzilla entry.
>
I've created some testdocument that reproduces the behaviour (where can files
be uploaded?). (WinXP)
-> 1.6.1 (AltInstaller or Classic same behaviour): slow down in
On 2009-03-18, Richard Heck wrote:
> pseudo2...@gmx.at wrote:
>>> Child document opened alone or together with its parent?
>> For me it looks like heavy internal updating inside the master is done
>> for each included child-doc (it does not matter whether the child is
>> opend).
> I wish I had s
Well, I'll keep the traffic to the devel-list.
> I wish I had some idea why this is happening only on certain platforms.
> Or is it only on certain platforms? I've not seen reports of this
> behavior under Linux, but maybe there are people with similar problems.
>
> Have there been other change
Vincent van Ravesteijn - TNW wrote:
I wish I had some idea why this is happening only on
certain platforms. Or is it only on certain platforms?
I've not seen reports of this behavior under Linux, but
maybe there are people with similar problems.
Have there been other changes to the Windows or Ma
>I wish I had some idea why this is happening only on
>certain platforms. Or is it only on certain platforms?
>I've not seen reports of this behavior under Linux, but
>maybe there are people with similar problems.
>
>Have there been other changes to the Windows or Mac distributions from
>1.6.1 to 1
pseudo2...@gmx.at wrote:
Child document opened alone or together with its parent?
Performance inside the child document is much better. Only the master is
concerned. It does not matter whether the master is opened or not. It even does
not make any difference if the master or the child is
Hi all,
thank Abdelrazak Younes for the prompt answer.
so I'm not the only one (see users list: Lyx 1.6.2 unusably slow on the Mac)
> Child document opened alone or together with its parent?
Performance inside the child document is much better. Only the master is
concerned. It does not matter
pseudo2...@gmx.at wrote:
Hi all,
has anybody noticed some performance issues while editing inside a master
document that includes a number (say about 5 or more) of long child docs. The
same large document caused no problems in LyX 1.5.6
indication: cursor movement is annoyingly slow, fast typ
41 matches
Mail list logo
