On Wed, May 30, 2007 at 08:37:09AM +0200, Abdelrazak Younes wrote: > Andre Poenitz wrote: > >On Tue, May 29, 2007 at 10:11:16PM +0200, Stefan Schimanski wrote: > >>I enabled stdlib-debug and then were surprised about the slowness. > >>Some profiling was full of signal/slot stuff in copying cursors.... > > > >Well, I am not complaining about slowness (which hardly can be judged > >by a non-optimized build) but about the concept. If we need some kind > >of checked iterators (and we probably do) this should be done properly > >by e.g. registering the iterators with the buffers or such, not by > >working around symptoms by invalidating single slices. > > I am not sure that registering every single DocIterator would be any > more efficient that my signal/slot solution. At the end you will have to > go through a table.
It would be a robust solution. > >What makes me really angry is that I thought I was clear enough when > >I put > > If you are angry, then I suggest that, in the future you should more > closely follow the list and comment when the changes are proposed. Please give a pointer to the relevant discussion on lyx-devel. Even an admittedly quick look through the archives does not bring up anything that looks like it. > > // Do not add _any_ (non-static) data members as this would inflate > > // everything storing large quantities of insets. Mathed e.g. would > > // suffer. > > > >into Inset.h. > >Yet we get an int in each inset for its background color (very > >important! and only 4 bytes!), > > Which was there in InsetOld and InsetMathSomething anyway. > So every inset had it! Wrong. svn diff -r 17912:17913. Not even a single math inset touched. And style issues with this patch as well so I doubt I have not seen this dicussion either. > I don't know why you are angry that I made that explicit. > > >an in-inset Dimension cache (12 bytes) > > About the same situation as above. Again wrong. The most commonly used math inset (InsetMathChar) had no dimension cache. For a very good reason that was even written down. > >when the whole system was designed to work without that, and now a mere > >20 additional bytes for a signal that's used in a half-baked solution > >to plaster over conceptional shortcomings in someone's pet feature. > > Wrong, this is safe for non-multiview too! And I am pretty sure of that: > think externally modified file. > > >With this kind of 'improvement' (and others in the 1.5 cycle) we are now > >happily spending 48(!) bytes for every single character in mathed (and > >every time when a copy of it ends up on the undo stack) for what took 12 > >bytes six months ago. > > That is true but I reckon that there is more to it anyway. I've checked > the memory consumption of a big document full of math with and without > this signal an you know what? There is no sensible difference. It's not 'loading a document full of math', it's 'working on a document with math'. You obviously never did that. Konni has files with formulas spanning several pages. These easily several hundreds insets in LyX. Entering and editing this takes easily _several thousands_ operations. Each operation puts the whole thing on the undo stack, so even if this consisted only of 'cheap InsetMathChar', this eats several dozen MB. Reality is worse as there are even fatter insets. And that is for a single formula only. > >I think I stated this already earlier: LyX is _not_ ready for > >multiple views. > > You never proposed a single analysis to prove your statement. Now I > can say LyX _is_ ready for multiple views. You broke other areas just to make your pet appear healthy. Andre'
