Ok, I have my own numbers. This is what I obtained launching
LyX from the shell asking to open a document, and hitting Alt-F4
(close application) as soon as I see the LyX window. Note that,
before LyX is closed, I can see clearly the loaded document showing
on the screen, then the pressed sequence closes LyX (therefore
in the patched case, full par metrics and heights computation is done).
Note also that I didn't report numbers from the *first* execution,
but I repeated the process 3 or 4 times, then I reported the last
numbers. This is done to reach a "fair" condition in which all files
are basically cached in the Linux disk cache when launching the
program.
This is trunk, as checked out ~2 hour ago (USERGUIDE.LYX):
[EMAIL PROTECTED]:~/lyx-trunk$ time sudo nice ./src/lyx
lib/doc/UserGuide.lyx > /dev/null 2>&1
real 0m3.057s
user 0m2.127s
sys 0m0.112s
This is my scrollfix patch, as sent to the list tonight:
[EMAIL PROTECTED]:~/lyx-devel$ time sudo nice ./src/lyx
lib/doc/UserGuide.lyx > /dev/null 2>&1
real 0m2.611s
user 0m1.719s
sys 0m0.110s
And now again trunk for EMBEDDEDOBJECTS.LYX:
[EMAIL PROTECTED]:~/lyx-trunk$ time sudo nice ./src/lyx
lib/doc/EmbeddedObjects.lyx > /dev/null 2>&1
real 0m2.887s
user 0m1.912s
sys 0m0.141s
and again my scrollfix patch:
[EMAIL PROTECTED]:~/lyx-devel$ time sudo nice ./src/lyx
lib/doc/EmbeddedObjects.lyx > /dev/null 2>&1
real 0m3.156s
user 0m2.269s
sys 0m0.106s
Conclusions: the unscientific experiment of Andre Poenits was really
non-scientific.
I guess he must have left debug enabled when trying the scrollfix, and
disabled in the
other case :-) Another possibility could be he tried the scrollfix with
an empty disk
cache, then trunk with a filled disk-cache. The difference is enormous,
as shown below:
This is what happens to trunk if I clear the disk cache:
[EMAIL PROTECTED]:~# sync && echo 3 > /proc/sys/vm/drop_caches
[EMAIL PROTECTED]:~/lyx-trunk$ time sudo nice ./src/lyx
lib/doc/EmbeddedObjects.lyx > /dev/null 2>&1
real 0m18.461s
user 0m1.952s
sys 0m0.195s
and this is my scrollfix after the same process:
[EMAIL PROTECTED]:~# sync && echo 3 > /proc/sys/vm/drop_caches
[EMAIL PROTECTED]:~/lyx-devel$ time sudo nice ./src/lyx
lib/doc/EmbeddedObjects.lyx > /dev/null 2>&1
real 0m19.146s
user 0m2.268s
sys 0m0.187s
As you can see, ~20 seconds are needed to load LyX along with all the
shared libraries
it uses, configuration files, and the document itself. The time actually
spent by the
CPU does not change that much (~2 sec.).
If anyone has a longer file (a Master thesis, PhD thesis or something
like that), I
can try to see what is the doc length at which things start really
slowing down
inaccpetably.
T.
Tommaso Cucinotta ha scritto:
Andre Poenitz ha scritto:
An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for all of those
nine extra seconds.
So please: Produce some numbers showing that there are no inacceptable
regressions wrt to performance. A performance degradation by a factor of
3 for loading documents does not look like a good start.
Well, I'm verifying on my laptop. But I want to be sure to have
two LyX compiled exactly with the same options, and debug
disabled. On my laptop ([EMAIL PROTECTED]), it takes ~30min. a full
recompilation of LyX, so I guess I'll have numbers within one
hour or so (and I'm also deleting a couple of kernel source
trees to accomodate for the needed space).
Anyway, please note that, with the current patch, *all* par
metrics and heights are pre-computed on a document load
(full metrics are discarded for all pars but the visible ones),
so I expect anycase a slow-down on document opening. As
already mentioned on the list, I'd like to switch to an
incremental computation of the document height that is
made in the background while the user is already able to
work on the document.
I'd make such change as a further incremental patch, but if
you prefer the all-in-one approach, I can go further to such
step.
T.
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://feanor.sssup.it/~tommaso
