On Friday 22 July 2005 5:14 pm, David Hampton wrote: > Really? My way. Load the function argument (1) and function address > (2), call the is_dirty subroutine (1), load the structure offset (1), > read the value (1), return (1). Depeneding on whether or not a stack > frame is needed add another 3 instructions. 7 to 10 total instructions.
You're neglecting all the extra calls back to the book during editing when it is already dirty. Why bother? The dirty flag in the book is there for non-Collection data that may be added (using qof_book_set_data). When calling qof_book_not_saved() that's checked along with the collections. I really can't see any point in changing that. What we have will meet your needs, there's no need to add thousands of extra calls, all identical to the first. > > You need to call a function via the API and that function will check the > > collections. It really is no overhead. > > Its anywhere from the equivalent of what I'm proposing, to seven times > more work. I disagree, having the collections call the book at every single edit is pointless and wasteful. Just editing one transaction could fire off SIX of these edit calls - what's the point? It's bad enough setting this in the collection every time, that has to be done. The book does NOT need to be told every single time. It's a step too far for every single edit. When the book is asked, the book finds out and passes back the answer. Far easier. I'd rather have the current routine that is called infrequently than a call that is called for absolutely no reason at least once every time anything in the application is edited. > This *is* detecting the first change. And then it passes the call back for the next change and the one after that ad infinitum. This is getting us nowhere and just delaying the rest of the work. Can't we agree to disagree on this? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpBvB3cRw8yQ.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
