Re: ciruclar dependencies
On 05/29/2012 01:33 PM, Michael Stahl wrote: On 29/05/12 13:17, Tor Lillqvist wrote: the fastest way to start is still to load only the code that is necessary to start. Isn't there something called demand paging that takes care of that? it is supposed to do this, but falls short when it comes to startup performance on rotating storage, which is why we have various platform specific hacks to do linear reads of all libraries required at startup in order to hide the seek latencies incurred by demand paging. It also falls short on avoiding the runtime loader's work on relocations in data segments, execution of .init sections, etc. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ciruclar dependencies
Sigh, OK then, everything is already perfect. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ciruclar dependencies
On 25/05/12 17:49, Tor Lillqvist wrote: i believe cyclical dependencies indicate bad architecture. if 2 modules depend on each other, then either they should be changed not to depend on each other, or merged into one module. Hear, hear. Do you include run-time dependency in that? Like the couple of places where dynamic linking is used, to enable code in library A that depends on library B at compile-time to be used from library B at run-time. (I.e. B loads A and looks up one or a few functions from it dynamically.) that kind of thing isn't particularly elegant, but in specific cases there may be good reasons to do it in order to improve performance. if the stuff in library B is used rarely, then splitting it out and loading it on demand can improve startup performance, see e.g. the msword library in sw, which is completely unnecessary if you create a new document, or only use ODF; the fastest way to start is still to load only the code that is necessary to start. of course, if the stuff in library B is always loaded on every use of something in library A it doesn't make sense to split them. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ciruclar dependencies
which is completely unnecessary if you create a new document, or only use ODF On the other hand, if you never use ODF, you still have to load the code for it? the fastest way to start is still to load only the code that is necessary to start. Isn't there something called demand paging that takes care of that? Why stop at the arbitrary division of libraries as they happen to exist now; I am sure one could as well come up with dozens of other classes of functionality that some group of users don't need when starting up? But, whatever. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ciruclar dependencies
On 29/05/12 13:17, Tor Lillqvist wrote: which is completely unnecessary if you create a new document, or only use ODF On the other hand, if you never use ODF, you still have to load the code for it? that's an unfortunate side effect of how the ODF filter is implemented in Writer: mostly it accesses the document via UNO API, but some parts (tables especially) are intimately tied up with the Writer core, and so there are Writer specific sub-classes of stuff from xmloff in sw/source/filter/xml, and so sw is linked against xmloff. no, wait, that is actually a side issue, of course the ODF filter could be split out into a separate library, but i guess since ODF is the default file format it makes less sense to do that than other formats; i don't have a strong opinion either way in this case. i guess it could make sense to split out some of the other filters that are still linked into libsw, but i wonder if that in practice means only HTML nowadays (the ASCII one has surprising users in core). the fastest way to start is still to load only the code that is necessary to start. Isn't there something called demand paging that takes care of that? it is supposed to do this, but falls short when it comes to startup performance on rotating storage, which is why we have various platform specific hacks to do linear reads of all libraries required at startup in order to hide the seek latencies incurred by demand paging. Why stop at the arbitrary division of libraries as they happen to exist now; I am sure one could as well come up with dozens of other classes of functionality that some group of users don't need when starting up? certainly, the distribution of code across libraries is to a large extent an accumulation of historical accidents, so i guess many improvements are possible there. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ciruclar dependencies
On Fri, May 25, 2012 at 05:36:34PM +0200, Michael Stahl wrote: On 25/05/12 17:16, Stephan Bergmann wrote: On 05/25/2012 01:28 PM, David Tardon wrote: At the end, an anecdotical evidence about how far we progressed into gbuild land: the move of gtk/kde file pickers from fpicker to vcl introduced a dependency loop, because the pickers in vcl depend on headers from fpicker, but fpicker already (indirectly) depends on vcl. What is our attitude towards circular module dependencies in an all-gbuild scenario? My understanding is that technically they do not pose a problem. But how about them from a hygiene point of view? (And if we want to avoid them, would there be technical measures to do so?) i believe cyclical dependencies indicate bad architecture. if 2 modules depend on each other, then either they should be changed not to depend on each other, or merged into one module. Actually this was only because of one .hrc file, so I moved it from fpicker to vcl and everything is all right again. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ciruclar dependencies (was: feature/gbuild_merge needs testing)
On 05/25/2012 01:28 PM, David Tardon wrote: At the end, an anecdotical evidence about how far we progressed into gbuild land: the move of gtk/kde file pickers from fpicker to vcl introduced a dependency loop, because the pickers in vcl depend on headers from fpicker, but fpicker already (indirectly) depends on vcl. What is our attitude towards circular module dependencies in an all-gbuild scenario? My understanding is that technically they do not pose a problem. But how about them from a hygiene point of view? (And if we want to avoid them, would there be technical measures to do so?) Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ciruclar dependencies
On 25/05/12 17:16, Stephan Bergmann wrote: On 05/25/2012 01:28 PM, David Tardon wrote: At the end, an anecdotical evidence about how far we progressed into gbuild land: the move of gtk/kde file pickers from fpicker to vcl introduced a dependency loop, because the pickers in vcl depend on headers from fpicker, but fpicker already (indirectly) depends on vcl. What is our attitude towards circular module dependencies in an all-gbuild scenario? My understanding is that technically they do not pose a problem. But how about them from a hygiene point of view? (And if we want to avoid them, would there be technical measures to do so?) i believe cyclical dependencies indicate bad architecture. if 2 modules depend on each other, then either they should be changed not to depend on each other, or merged into one module. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ciruclar dependencies
i believe cyclical dependencies indicate bad architecture. if 2 modules depend on each other, then either they should be changed not to depend on each other, or merged into one module. Hear, hear. Do you include run-time dependency in that? Like the couple of places where dynamic linking is used, to enable code in library A that depends on library B at compile-time to be used from library B at run-time. (I.e. B loads A and looks up one or a few functions from it dynamically.) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
