I think another thing to consider is that for e.g. QRect with a bunch of inline functions, the compiler might inline it, or it might emit copies of the function in TUs where it sees repeated usage. In my test where a class was using each function from QRect once, my patch was enough to make it inline. But that's not really a realistic scenario :)
Though like Thiago was hinting at, I don't know how safe it would be to make this change wrt. especially inheritance. Mårten ________________________________________ From: Development <[email protected]> on behalf of Philippe <[email protected]> Sent: Tuesday, June 9, 2026 12:16 To: [email protected] Subject: Re: [Development] MSVC not inlining QRect inline functions (anymore?) My final findings are: /Ob3 causes inlining of much more code, like QPoint or QMargins, etc. My release binary size increases by +11% when using /Ob3. I can understand why Microsoft doesn't promote that option much. At the same time, it's unfortunate that /Ob3 is needed to inline tiny classes such as QPoint. As for QPolygon, there's no inlining (I only checked setPoint). >> It's not worth my time to work around even more shortcomings of MSVC Totally understandable. If improvement comes, it should be from Microsoft's compiler team. Philippe On Mon, 08 Jun 2026 16:48:42 -0700 Thiago Macieira <[email protected]> wrote: > On Monday, 8 June 2026 14:06:34 Pacific Daylight Time Philippe wrote: > > > Can you try /Ob3 ? > > > > Yes it works! > > But only with both /Ob3 and Mårten's patch > > (https://codereview.qt-project.org/c/qt/qtbase/+/742796) > > I'm not sure how safe that is. I raise you QPolygon. > > See Qt 5's qvector.h: > https://github.com/qt/qtbase/blob/v5.15.0/src/corelib/tools/qvector.h#L1119-L1132 > > This problem is a reason to follow Marc's advice and not to export the whole > class. But the fix was in QPolygon, not QVector. So even if we don't export > the > class, someone deriving from it and exporting their own class may cause our > class to get exported in their DLL's ABI. > > I'm personally going to spend mental cycles trying to figure this out. It's > not > worth my time to work around even more shortcomings of MSVC, especially when > it comes to performance (we've had to forbid LTO/LTCG mode for it, because it > appears to be broken). The ball is on Microsoft's court. And while they're at > it, they could fix data dllimports and add IFUNC support. > > Other people are welcome to spend time figuring this out. But a patch to > QtCore > needs to convince me beyond doubt, because I'm the one who ends up having to > maintain these hacks when they break. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Principal Engineer - Intel DCG - Platform & Sys. Eng. -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
