To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=100757
------- Additional comments from mme...@openoffice.org Tue Apr 7 14:20:41 +0000 2009 ------- So - perhaps I am not clear. Having determined, after some work, that it is fundamentally unreasonable to load or execute a given chunk of code during startup [ eg. a spell-checking / dictionary service - which is only valid at idle ], and done the work to ensure that it is no longer loaded by accident: we want to ensure that if by some accident [ no-one is aware of all the side-effects their code changes introduce ] it is re-introduced, that we quickly catch and remove the performance regression. > Actually, this could be achieved by simply extending e.g. the > Uno Reference class to support on-demand instantiation, the > moment an object is needed it becomes created ... But the problem is that, whatever you do here, code will be added that inadvertently does ~something on startup; whatever you do. > This does not address the issue, that anybody may retrieve an > object to do something, which could be done later. Right - which is ultimately the real problem; most people don't create UNO object references just for fun ;-) > The overall underlying problem is the fact, that the start-up has been > programmed explicitly, by sequence of statements creating this, > initializing that, all under the assumption, that the author knows > the dependencies. Is this not the very nature of programming ? even in some abstract asynchronous system we would want to discover and exclude "slow things" from the initialisation sequence by re-ordering events etc. > I think every reasonable experienced engineer does know how to do > this start-up thing right, though most just try to fetch some low > hanging fruits, avoiding some bigger refactorings. My experience is the opposite; that despite work, more and more cruft creeps back into the startup sequence, and that it gets slower over time. > We may want to utilize the suggested helper assertions, though I feel > / fear, that this "hack" would never become removed again ... Why is it a hack to have a clearly defined startup state from the beginning of Desktop:Main up to 'Execute' during which time, we tag code that we know to be expensive, to ensure it doesn't occur there ? Surely this is just adding a valuable annotation to the code, that neither the compiler, nor programmer can easily deduce. And of course, it need say nothing in the Sun builds - all I want is the 'sal' naming daemons to provide a rubber-stamped official name for the macro & ~2-3 methods to allow this to be used ~everywhere. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lingucomponent.openoffice.org For additional commands, e-mail: issues-h...@lingucomponent.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
