Re: lyx 1.6rc4 ultra slow to load document
José Matos [EMAIL PROTECTED] writes: On Monday 27 October 2008 15:29:05 Jean-Marc Lasgouttes wrote: José Matos [EMAIL PROTECTED] writes: So yes it should be possible to speed the conversion but there are reasons for the slow response. Up until this moment we have focused on making it correct, and just after we should make it fast. :-) It seems that this time has come :) OK. I think that I have found the culprit. Good boy! JMarc
Re: lyx 1.6rc4 ultra slow to load document
José Matos [EMAIL PROTECTED] writes: On Monday 27 October 2008 15:29:05 Jean-Marc Lasgouttes wrote: José Matos [EMAIL PROTECTED] writes: So yes it should be possible to speed the conversion but there are reasons for the slow response. Up until this moment we have focused on making it correct, and just after we should make it fast. :-) It seems that this time has come :) OK. I think that I have found the culprit. Good boy! JMarc
Re: lyx 1.6rc4 ultra slow to load document
José Matos <[EMAIL PROTECTED]> writes: > On Monday 27 October 2008 15:29:05 Jean-Marc Lasgouttes wrote: >> José Matos <[EMAIL PROTECTED]> writes: >> > So yes it should be possible to speed the conversion but there are >> > reasons for the slow response. Up until this moment we have focused on >> > making it correct, and just after we should make it fast. :-) >> >> It seems that this time has come :) > > OK. I think that I have found the culprit. Good boy! JMarc
Re: lyx 1.6rc4 ultra slow to load document
On Sunday 26 October 2008 20:38:45 Jean-Marc Lasgouttes wrote: Abdelrazak Younes [EMAIL PROTECTED] writes: You are not. We should probably indicate more prominently that a conversion is taking place. And more importantly we should do basic profiling on lyx2lyx. I guess this is possible in python? Yes, it is. There is even some framework in place to test it directly. What happens, and I have seen this before is that we are starting to see documents converted from lyx 1.3 to 1.6 that has more than 120 conversions where in most of them we scan the document line by line. So yes it should be possible to speed the conversion but there are reasons for the slow response. Up until this moment we have focused on making it correct, and just after we should make it fast. :-) JMarc -- José Abílio
Re: lyx 1.6rc4 ultra slow to load document
José Matos [EMAIL PROTECTED] writes: So yes it should be possible to speed the conversion but there are reasons for the slow response. Up until this moment we have focused on making it correct, and just after we should make it fast. :-) It seems that this time has come :) JMarc
Re: lyx 1.6rc4 ultra slow to load document
On Monday 27 October 2008 15:29:05 Jean-Marc Lasgouttes wrote:
José Matos [EMAIL PROTECTED] writes:
So yes it should be possible to speed the conversion but there are
reasons for the slow response. Up until this moment we have focused on
making it correct, and just after we should make it fast. :-)
It seems that this time has come :)
OK. I think that I have found the culprit.
Attached follows a patch to lyx_1_6.py that cut the conversion time from 63 to
10 seconds in one of my recent slowest examples.
FWIW the problem was that the unicode symbols were being read on each call of
the functions that need them. In the case above that happened 918 times (!).
I would appreciate the testing of this patch. The patch is straightforward and
it should be correct.
JMarc
--
José Abílio
Index: lyx_1_6.py
===
--- lyx_1_6.py (revision 27154)
+++ lyx_1_6.py (working copy)
@@ -242,6 +242,8 @@
return retval
+unicode_reps = read_unicodesymbols()
+
#Bug 5022
#Might should do latex2ert first, then deal with stuff that DOESN'T
#end up inside ERT. That routine could be modified so that it returned
@@ -257,12 +259,11 @@
retval = []
# Convert LaTeX to Unicode
-reps = read_unicodesymbols()
# Commands of this sort need to be checked to make sure they are
# followed by a non-alpha character, lest we replace too much.
hardone = re.compile(r'^[a-zA-Z]+$')
-for rep in reps:
+for rep in unicode_reps:
if hardone.match(rep[0]):
pos = 0
while True:
@@ -315,7 +316,6 @@
# clean up multiline stuff
content =
ert_end = 0
-reps = read_unicodesymbols()
for curline in range(len(lines)):
line = lines[curline]
@@ -372,7 +372,7 @@
line = line.replace('$', '\\${}')
# Do the LyX text -- LaTeX conversion
- for rep in reps:
+ for rep in unicode_reps:
line = line.replace(rep[1], rep[0] + {})
line = line.replace(r'\backslash', r'\textbackslash{}')
line = line.replace(r'\series bold', r'\bfseries{}').replace(r'\series default', r'\mdseries{}')
Re: lyx 1.6rc4 ultra slow to load document
José Matos wrote: On Monday 27 October 2008 15:29:05 Jean-Marc Lasgouttes wrote: José Matos [EMAIL PROTECTED] writes: So yes it should be possible to speed the conversion but there are reasons for the slow response. Up until this moment we have focused on making it correct, and just after we should make it fast. :-) It seems that this time has come :) OK. I think that I have found the culprit. Attached follows a patch to lyx_1_6.py that cut the conversion time from 63 to 10 seconds in one of my recent slowest examples. FWIW the problem was that the unicode symbols were being read on each call of the functions that need them. In the case above that happened 918 times (!). I would appreciate the testing of this patch. The patch is straightforward and it should be correct. Mea culpa. I think I must have had it the way you have it at some point. I do remember thinking about this. (Maybe what I did, actually, was move it out of a loop.) Anyway, I can't imagine that this patch isn't correct. rh
Re: lyx 1.6rc4 ultra slow to load document
On Sunday 26 October 2008 20:38:45 Jean-Marc Lasgouttes wrote: Abdelrazak Younes [EMAIL PROTECTED] writes: You are not. We should probably indicate more prominently that a conversion is taking place. And more importantly we should do basic profiling on lyx2lyx. I guess this is possible in python? Yes, it is. There is even some framework in place to test it directly. What happens, and I have seen this before is that we are starting to see documents converted from lyx 1.3 to 1.6 that has more than 120 conversions where in most of them we scan the document line by line. So yes it should be possible to speed the conversion but there are reasons for the slow response. Up until this moment we have focused on making it correct, and just after we should make it fast. :-) JMarc -- José Abílio
Re: lyx 1.6rc4 ultra slow to load document
José Matos [EMAIL PROTECTED] writes: So yes it should be possible to speed the conversion but there are reasons for the slow response. Up until this moment we have focused on making it correct, and just after we should make it fast. :-) It seems that this time has come :) JMarc
Re: lyx 1.6rc4 ultra slow to load document
On Monday 27 October 2008 15:29:05 Jean-Marc Lasgouttes wrote:
José Matos [EMAIL PROTECTED] writes:
So yes it should be possible to speed the conversion but there are
reasons for the slow response. Up until this moment we have focused on
making it correct, and just after we should make it fast. :-)
It seems that this time has come :)
OK. I think that I have found the culprit.
Attached follows a patch to lyx_1_6.py that cut the conversion time from 63 to
10 seconds in one of my recent slowest examples.
FWIW the problem was that the unicode symbols were being read on each call of
the functions that need them. In the case above that happened 918 times (!).
I would appreciate the testing of this patch. The patch is straightforward and
it should be correct.
JMarc
--
José Abílio
Index: lyx_1_6.py
===
--- lyx_1_6.py (revision 27154)
+++ lyx_1_6.py (working copy)
@@ -242,6 +242,8 @@
return retval
+unicode_reps = read_unicodesymbols()
+
#Bug 5022
#Might should do latex2ert first, then deal with stuff that DOESN'T
#end up inside ERT. That routine could be modified so that it returned
@@ -257,12 +259,11 @@
retval = []
# Convert LaTeX to Unicode
-reps = read_unicodesymbols()
# Commands of this sort need to be checked to make sure they are
# followed by a non-alpha character, lest we replace too much.
hardone = re.compile(r'^[a-zA-Z]+$')
-for rep in reps:
+for rep in unicode_reps:
if hardone.match(rep[0]):
pos = 0
while True:
@@ -315,7 +316,6 @@
# clean up multiline stuff
content =
ert_end = 0
-reps = read_unicodesymbols()
for curline in range(len(lines)):
line = lines[curline]
@@ -372,7 +372,7 @@
line = line.replace('$', '\\${}')
# Do the LyX text -- LaTeX conversion
- for rep in reps:
+ for rep in unicode_reps:
line = line.replace(rep[1], rep[0] + {})
line = line.replace(r'\backslash', r'\textbackslash{}')
line = line.replace(r'\series bold', r'\bfseries{}').replace(r'\series default', r'\mdseries{}')
Re: lyx 1.6rc4 ultra slow to load document
José Matos wrote: On Monday 27 October 2008 15:29:05 Jean-Marc Lasgouttes wrote: José Matos [EMAIL PROTECTED] writes: So yes it should be possible to speed the conversion but there are reasons for the slow response. Up until this moment we have focused on making it correct, and just after we should make it fast. :-) It seems that this time has come :) OK. I think that I have found the culprit. Attached follows a patch to lyx_1_6.py that cut the conversion time from 63 to 10 seconds in one of my recent slowest examples. FWIW the problem was that the unicode symbols were being read on each call of the functions that need them. In the case above that happened 918 times (!). I would appreciate the testing of this patch. The patch is straightforward and it should be correct. Mea culpa. I think I must have had it the way you have it at some point. I do remember thinking about this. (Maybe what I did, actually, was move it out of a loop.) Anyway, I can't imagine that this patch isn't correct. rh
Re: lyx 1.6rc4 ultra slow to load document
On Sunday 26 October 2008 20:38:45 Jean-Marc Lasgouttes wrote: > Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > You are not. We should probably indicate more prominently that a > > conversion is taking place. > > And more importantly we should do basic profiling on lyx2lyx. I guess > this is possible in python? Yes, it is. There is even some framework in place to test it directly. What happens, and I have seen this before is that we are starting to see documents converted from lyx 1.3 to 1.6 that has more than 120 conversions where in most of them we scan the document line by line. So yes it should be possible to speed the conversion but there are reasons for the slow response. Up until this moment we have focused on making it correct, and just after we should make it fast. :-) > JMarc -- José Abílio
Re: lyx 1.6rc4 ultra slow to load document
José Matos <[EMAIL PROTECTED]> writes: > So yes it should be possible to speed the conversion but there are > reasons for the slow response. Up until this moment we have focused on > making it correct, and just after we should make it fast. :-) It seems that this time has come :) JMarc
Re: lyx 1.6rc4 ultra slow to load document
On Monday 27 October 2008 15:29:05 Jean-Marc Lasgouttes wrote:
> José Matos <[EMAIL PROTECTED]> writes:
> > So yes it should be possible to speed the conversion but there are
> > reasons for the slow response. Up until this moment we have focused on
> > making it correct, and just after we should make it fast. :-)
>
> It seems that this time has come :)
OK. I think that I have found the culprit.
Attached follows a patch to lyx_1_6.py that cut the conversion time from 63 to
10 seconds in one of my recent slowest examples.
FWIW the problem was that the unicode symbols were being read on each call of
the functions that need them. In the case above that happened 918 times (!).
I would appreciate the testing of this patch. The patch is straightforward and
it should be correct.
> JMarc
--
José Abílio
Index: lyx_1_6.py
===
--- lyx_1_6.py (revision 27154)
+++ lyx_1_6.py (working copy)
@@ -242,6 +242,8 @@
return retval
+unicode_reps = read_unicodesymbols()
+
#Bug 5022
#Might should do latex2ert first, then deal with stuff that DOESN'T
#end up inside ERT. That routine could be modified so that it returned
@@ -257,12 +259,11 @@
retval = []
# Convert LaTeX to Unicode
-reps = read_unicodesymbols()
# Commands of this sort need to be checked to make sure they are
# followed by a non-alpha character, lest we replace too much.
hardone = re.compile(r'^[a-zA-Z]+$')
-for rep in reps:
+for rep in unicode_reps:
if hardone.match(rep[0]):
pos = 0
while True:
@@ -315,7 +316,6 @@
# clean up multiline stuff
content = ""
ert_end = 0
-reps = read_unicodesymbols()
for curline in range(len(lines)):
line = lines[curline]
@@ -372,7 +372,7 @@
line = line.replace('$', '\\${}')
# Do the LyX text --> LaTeX conversion
- for rep in reps:
+ for rep in unicode_reps:
line = line.replace(rep[1], rep[0] + "{}")
line = line.replace(r'\backslash', r'\textbackslash{}')
line = line.replace(r'\series bold', r'\bfseries{}').replace(r'\series default', r'\mdseries{}')
Re: lyx 1.6rc4 ultra slow to load document
José Matos wrote: On Monday 27 October 2008 15:29:05 Jean-Marc Lasgouttes wrote: José Matos <[EMAIL PROTECTED]> writes: So yes it should be possible to speed the conversion but there are reasons for the slow response. Up until this moment we have focused on making it correct, and just after we should make it fast. :-) It seems that this time has come :) OK. I think that I have found the culprit. Attached follows a patch to lyx_1_6.py that cut the conversion time from 63 to 10 seconds in one of my recent slowest examples. FWIW the problem was that the unicode symbols were being read on each call of the functions that need them. In the case above that happened 918 times (!). I would appreciate the testing of this patch. The patch is straightforward and it should be correct. Mea culpa. I think I must have had it the way you have it at some point. I do remember thinking about this. (Maybe what I did, actually, was move it out of a loop.) Anyway, I can't imagine that this patch isn't correct. rh
Re: lyx 1.6rc4 ultra slow to load document
Abdelrazak Younes [EMAIL PROTECTED] writes: You are not. We should probably indicate more prominently that a conversion is taking place. And more importantly we should do basic profiling on lyx2lyx. I guess this is possible in python? JMarc
Re: lyx 1.6rc4 ultra slow to load document
Abdelrazak Younes [EMAIL PROTECTED] writes: You are not. We should probably indicate more prominently that a conversion is taking place. And more importantly we should do basic profiling on lyx2lyx. I guess this is possible in python? JMarc
Re: lyx 1.6rc4 ultra slow to load document
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > You are not. We should probably indicate more prominently that a > conversion is taking place. And more importantly we should do basic profiling on lyx2lyx. I guess this is possible in python? JMarc
lyx 1.6rc4 ultra slow to load document
Hi all. I'm not sure this is a problem or just reflects the unfinished state of lyx 1.6. But I have a large-ish document (about 140 pages when output to pdf). On my old slow laptop running lyx 1.5.6 (under gentoo linux btw) this loads in 2 seconds. On my fast, dual core amd64 architecture (also gentoo) the same document takes 37 seconds to load. Is this just debugging code or something slowing down the rc, or should I be worried? -- William Seager University of Toronto Scarborough www.utsc.utoronto.ca/~seager
Re: lyx 1.6rc4 ultra slow to load document
On 25/10/2008 17:49, William Seager wrote: Hi all. I'm not sure this is a problem or just reflects the unfinished state of lyx 1.6. But I have a large-ish document (about 140 pages when output to pdf). On my old slow laptop running lyx 1.5.6 (under gentoo linux btw) this loads in 2 seconds. On my fast, dual core amd64 architecture (also gentoo) the same document takes 37 seconds to load. Is this just debugging code or something slowing down the rc, or should I be worried? How long the UserGuide takes to load? If anything 1.6 should be faster to load any 1.6 document than 1.5 to load 1.5 documents, unless it was compiled with stdlib debug. I guess the 37 seconds you are seeing is probably due to lyx2lyx conversion. Please try to save your document in 1.6 format and then load it again. Be warned though that this won't be openable in 1.5 anymore, so make a backup. Abdel.
Re: lyx 1.6rc4 ultra slow to load document
On October 25, 2008 12:34:14 Abdelrazak Younes wrote: I guess the 37 seconds you are seeing is probably due to lyx2lyx conversion OK, I'm an idiot. Of course that was the problem - instant loading once the 1.6 format version was in place :) -- William Seager University of Toronto Scarborough www.utsc.utoronto.ca/~seager
Re: lyx 1.6rc4 ultra slow to load document
On 25/10/2008 19:26, William Seager wrote: On October 25, 2008 12:34:14 Abdelrazak Younes wrote: I guess the 37 seconds you are seeing is probably due to lyx2lyx conversion OK, I'm an idiot. You are not. We should probably indicate more prominently that a conversion is taking place. Of course that was the problem - instant loading once the 1.6 format version was in place :) Always nice to please philosophers ;-) Abdel.
lyx 1.6rc4 ultra slow to load document
Hi all. I'm not sure this is a problem or just reflects the unfinished state of lyx 1.6. But I have a large-ish document (about 140 pages when output to pdf). On my old slow laptop running lyx 1.5.6 (under gentoo linux btw) this loads in 2 seconds. On my fast, dual core amd64 architecture (also gentoo) the same document takes 37 seconds to load. Is this just debugging code or something slowing down the rc, or should I be worried? -- William Seager University of Toronto Scarborough www.utsc.utoronto.ca/~seager
Re: lyx 1.6rc4 ultra slow to load document
On 25/10/2008 17:49, William Seager wrote: Hi all. I'm not sure this is a problem or just reflects the unfinished state of lyx 1.6. But I have a large-ish document (about 140 pages when output to pdf). On my old slow laptop running lyx 1.5.6 (under gentoo linux btw) this loads in 2 seconds. On my fast, dual core amd64 architecture (also gentoo) the same document takes 37 seconds to load. Is this just debugging code or something slowing down the rc, or should I be worried? How long the UserGuide takes to load? If anything 1.6 should be faster to load any 1.6 document than 1.5 to load 1.5 documents, unless it was compiled with stdlib debug. I guess the 37 seconds you are seeing is probably due to lyx2lyx conversion. Please try to save your document in 1.6 format and then load it again. Be warned though that this won't be openable in 1.5 anymore, so make a backup. Abdel.
Re: lyx 1.6rc4 ultra slow to load document
On October 25, 2008 12:34:14 Abdelrazak Younes wrote: I guess the 37 seconds you are seeing is probably due to lyx2lyx conversion OK, I'm an idiot. Of course that was the problem - instant loading once the 1.6 format version was in place :) -- William Seager University of Toronto Scarborough www.utsc.utoronto.ca/~seager
Re: lyx 1.6rc4 ultra slow to load document
On 25/10/2008 19:26, William Seager wrote: On October 25, 2008 12:34:14 Abdelrazak Younes wrote: I guess the 37 seconds you are seeing is probably due to lyx2lyx conversion OK, I'm an idiot. You are not. We should probably indicate more prominently that a conversion is taking place. Of course that was the problem - instant loading once the 1.6 format version was in place :) Always nice to please philosophers ;-) Abdel.
lyx 1.6rc4 ultra slow to load document
Hi all. I'm not sure this is a problem or just reflects the unfinished state of lyx 1.6. But I have a large-ish document (about 140 pages when output to pdf). On my old slow laptop running lyx 1.5.6 (under gentoo linux btw) this loads in 2 seconds. On my fast, dual core amd64 architecture (also gentoo) the same document takes 37 seconds to load. Is this just debugging code or something slowing down the rc, or should I be worried? -- William Seager University of Toronto Scarborough www.utsc.utoronto.ca/~seager
Re: lyx 1.6rc4 ultra slow to load document
On 25/10/2008 17:49, William Seager wrote: Hi all. I'm not sure this is a problem or just reflects the unfinished state of lyx 1.6. But I have a large-ish document (about 140 pages when output to pdf). On my old slow laptop running lyx 1.5.6 (under gentoo linux btw) this loads in 2 seconds. On my fast, dual core amd64 architecture (also gentoo) the same document takes 37 seconds to load. Is this just debugging code or something slowing down the rc, or should I be worried? How long the UserGuide takes to load? If anything 1.6 should be faster to load any 1.6 document than 1.5 to load 1.5 documents, unless it was compiled with stdlib debug. I guess the 37 seconds you are seeing is probably due to lyx2lyx conversion. Please try to save your document in 1.6 format and then load it again. Be warned though that this won't be openable in 1.5 anymore, so make a backup. Abdel.
Re: lyx 1.6rc4 ultra slow to load document
On October 25, 2008 12:34:14 Abdelrazak Younes wrote: > I guess the 37 seconds you are seeing is probably due to lyx2lyx > conversion OK, I'm an idiot. Of course that was the problem - instant loading once the 1.6 format version was in place :) -- William Seager University of Toronto Scarborough www.utsc.utoronto.ca/~seager
Re: lyx 1.6rc4 ultra slow to load document
On 25/10/2008 19:26, William Seager wrote: On October 25, 2008 12:34:14 Abdelrazak Younes wrote: I guess the 37 seconds you are seeing is probably due to lyx2lyx conversion OK, I'm an idiot. You are not. We should probably indicate more prominently that a conversion is taking place. Of course that was the problem - instant loading once the 1.6 format version was in place :) Always nice to please philosophers ;-) Abdel.
