Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index



On Thu, 2012-02-23 at 11:24 +0100, Bjoern Michaelsen wrote:
Fixing the root problem might involve a git hook that gives you an angry stare
for 30 seconds everytime you add more lines to a >1.5KLOC hxx than you remove
from it.

        Heh ;-) IMHO a weighted stare-length based on how many times this
header is included might be more useful. Luckily we have that
information in an easy to consume form in the dependency information.

        We even have the easy hack:

        https://bugs.freedesktop.org/show_bug.cgi?id=42949

        :-)

bytes to parse    include count   size    filename
741439564         4454           166466   
solver/unxlngi6.pro/inc/boost/preprocessor/seq/fold_left.hpp 
416181480         6754           61620    solver/unxlngi6.pro/inc/rtl/ustring.hxx                   

        etc. ... I guess if we knew that it was discrete file accesses that
cause windows performance issues, we could easily triage the list for
small / trivial headers to merge.

        Failing that, boost-ification and gigantic 'left folding' headers
[urk?] will no doubt continue to harm compile times.

        I guess we'd want to encourage someone to take over from August on the
include-what-you-use front, but - that seems to suggest adding more
includes to compiling code so ... ;-)

        HTH,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.