Vincent van Ravesteijn wrote:
rgheck schreef:
Vincent van Ravesteijn - TNW wrote:
Hi All, I made a document with 60 graphics in it, I selected all,
and if I then
click somewhere to remove the selection, LyX treats me to one whole
minut to quickly brew some coffee.. Again, it has to do with file
access as the same for a graphic on a
local drive does not show this delay.
I won't be able to find out where the bug is till tomorrow evening.
Is this with Georg's patch, or without it?
rh
For the statistics:
With 2 graphics, there are 60 calls to FileName::==(),
With 20 graphics, there are 570 calls to FileName::==(),
With 60, graphics, there are 1760 calls to FileName::==(), which is at
least 10560 file accesses...
When deleting the 60 graphics, the count stops at 2160 times
FileName::==().. i.e. lunch break.
Georg's patch solves this, as the ==() operator isn't so expensive
most of the times.., but again, it makes no sense to compare that many
filenames to each other...
Please tell me why this is absolutely needed ;-)..
Not that I'm defending it, but here's what seems to be happening. When
you clear the selection, the selection itself is copied to the stack.
This triggers a series of calls to InsetGraphics::clone(), which
eventually creates a Loader (in GraphicsLoader) for the new
InsetGraphics, which eventually compares the old params with the new
ones, and that involves making sure the referenced files arethe same.
Hence the call to FileName::operator==. You get another call in
Loader::resetFile(), and there are a couple more checks triggered in
InsetGraphics::setParams(): One where we again compare the params, and
then another when RenderGraphic::update() yet resets the (same?) params.
Oh, and then there are even more, triggered by the Loader::Impl
destructor, which gets called from the InsetGraphics destructor.
I'd guess that some of this could be streamlined, but I don't know
anything about InsetGraphics myself.
rh
