On Fri, 2012-03-02 at 17:16 +0000, Caolán McNamara wrote: > Yeah, back the O[UString contents with direct new/delete calls in a real > implementation body instead of current thin header-only wrapper around > the C-API which backs onto rtl_allocateMemory/rtl_freeMemory.
I'm really rather convinced that we shouldn't be piling up huge amounts of exception unwind information, and crippling our optimiser by terrifying it with lots of things that never really happen. At the most banal level, I suspect that: struct Empty { int unused; }; Empty *p = new Empty(); delete p; can't legitimately be optimised away if we have a throwing constructor, but of course I can dig out some compiler people who know what they're on about here. Consistently calling std::abort() somewhere rather than waiting for a SEGV sounds fine, though preferably not in-lined into many tens if not hundreds of thousands of duplicate compare/branch/call-function sides at every object construction. Compared with that sort of waste, using the CPU's beautiful, efficient, built-in exception handling mechanism that requires zero code, and no unwind table ;-) *((int *)NULL) = 42; makes some sense. I don't find the explanation that most C++ object allocation wastes space left and right a great argument for doing yet more wastage :-) indeed, having an allocator that does not throw sounds quite sensible to me. The size of our binaries is already quite staggering given how relatively little they do. > Alternative, replace rtl_allocateMemory/rtl_freeMemory in strtmpl.cxx > with new/delete, and remove the inline bad_alloc throwing from the > header and assume that there isn't any existing users of the c-api that > ever checked that rtl_uString2String failed I guess I now need to go and characterise how much of the saving is from removing tens of thousands of in-lined 'if (baa) throw std::bad_alloc();' calls vs. the exception unwind and knock-on optimiser impact of having all that there. Sigh, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice