Hi Noel, Noel Grandin wrote: > That is kind of my point - here we have gratutious use of UNO, with > no real means of an extension using it, which is just making it > harder to optimise an important of our system. > The main point I'm disputing is the 'making it harder to optimise'. From the patch, nothing prevents you from granting direct, c++-level access to internal data, _and_ keeping UNO in place. So without arguing the merits of whether UNO is useful for drawinglayer/svg, you're mixing two unrelated changes into one patch. > (1) Unnecessary copying because of UNO shows up heavily in various places. > Mostly because we can't pass large complex data directly. > Problem of API design. We have examples of complex data structures wrapped in UNO interfaces (and direct, c++-level access to implementation if necessary for speed). > (2) Lots of UNO classes need to have their own Mutex object because > they can get called from multiple threads, so it is not just > SolarMutex. > For graphics stuff, that's a non sequitur - we can just grab SolarMutex on the outer layer. > (3) Even where UNO is not itself a perf problem, it introduces > indirection because it is much harder to figure out what code is > being called and who is calling it > That's mostly true for the heavily property-based interfaces for our document APIs, that then largely affect filter code. > (4) Touching UNO is an expensive exercise, involving attempted > analysis of external usage, awkardness introducing modifications > to API, etc, etc (and this coming from someone who __likes__ > UNO) > Yep, that's true. Cheers, -- Thorsten
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
