>> For each keystroke, updateMacros() is called, which calls > >Ouch! >Isn't this something that is necessary only if you're actually >dealing with a macro? (making one, or filling in parameters)? >If so, perhaps check that first and just return if there is >nothing macroish to do?
As far as I understood, there are links to macros stored in a table. This means that the table says that Macro_x is used in paragraph 10, position 12 etc. If the document changes, one has to adjust these numbers as the location might now be paragraph 11, position 12 after a new paragraph is inserted. >> InsetInclude::loadIfNeeded(), which then calls >> theBufferList::getBuffer(). This function iterates over all loaded >> buffers and if the wanted file is not loaded yet it will be loaded. >> >I have a hard time understanding why any kind of filesystem check might >be necessary on _each keystroke_. Move the cursor into a file-backed >inset - sure. But not otherwise? The main LyX job is typing text and >that ought to work with a minimum of per-keystroke checks. I guess this >behaviour is unintentional. It shouldn't be necessary. It is just checked whether these buffers are already loaded (in an apparently clumsy way). >> As a consequence, having 5 child documents leads to comparing >> 2+3+4+5+6=20 times two filenames. > >And the quadratic behaviour indicates that something else is amiss too. > Well, this could be easier, but a modern pc should be able to compare a lots of strings without any delay. So, this shouldn't be very disastrous. >Much development happens on linux, where excellent file caching hides >this silliness/mistake. (No network access if the process asks about >the same few files over and over.) And a fast processor hides the >actual work in searching the file cache. That might explain it. >It is a good thing some have slow machines or slow filesystems, >catching such things. Perhaps there is too much encapsulation, >hiding details from programmers. If the hidden stuff is well-designed, encapsulation shouldn't be a problem and should make life much easier for the programmer. That's the main reason I would like to redesign this FileName class. It would be nice to provide a simple class that handles all different os'es etc, and that also is optimized not to access the filesystem too often. Of course, the other things might not be perfect, but if the 'hidden' stuff is optimized, then the programmer should not have to think over and over again about the same things in different places. >Helge Hafting Vincent
