# some tweaks ?

**URL:** <https://forum.collaboraonline.com/t/some-tweaks/5109>\
**Category:** Development\
**Created:** [October 5, 2026, 6:15pm UTC](https://forum.collaboraonline.com/t/some-tweaks/5109 "2026-10-05T18:15:09Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![sberg](https://avatars.discourse-cdn.com/v4/letter/s/e274bd/32.png) [@sberg](https://forum.collaboraonline.com/u/sberg)\
**Post date:** [October 6, 2026, 6:42am UTC](https://forum.collaboraonline.com/t/some-tweaks/5109/2 "2026-10-06T06:42:03Z")

</div>

> ```
> I was just wondering about a few tweaks we could make to cleanup and perhaps even accelerate the compilation \- and I imagine others might have some ideas\.
> 
> ```

(I'd assume none of the below has much if any impact on build performance, but is valid cleanup anyway:)

> \* kill internal\_only ?
> 
> ```
> I was wondering \- do we need this:
> 
> \#define LIBO\_INTERNAL\_ONLY
> 
> anymore, since our APIs are now internal anyway; might be worth a clean\.
> 
> ```

Yes, the few remaining uses of `LIBO_INTERNAL_ONLY` and its definition in `engine/solenv/gbuild/gbuild.mk` etc. could be cleaned up now.

> \* out-line the OUString methods as C++ methods:
> 
> ```
> I suspect that \(at least for non PCH builds\), that rtl/oustring\.hxx and rtl/ostring\.hxx would be better using their functional call indirection as a C\+\+ function call rather than compiling and inlining this C method call and then taking the indirection there all over the place\.
> 
> ```

A bit hard to decipher what the above paragraph wants to say---but yes, like for the next item, we probably no longer need a C API, and definitely no longer have a C ABI, so any `extern "C"` functions from that old API/ABI can likely be replaced with plain C++ functions now. (The caveat for this and for the next item is to first check that we indeed no longer have any C translation units making use of any of this.)

[...]\> Then again some things like:

> ```
> bool equalsIgnoreAsciiCaseAsciiL\( const char \* asciiStr, sal\_Int32 asciiStrLength \) const
> \{
> if \( pData\-&gt;length \!= asciiStrLength \)
> return false;
> 
> return rtl\_ustr\_ascii\_compareIgnoreAsciiCase\_WithLength\( pData\- &gt;buffer, pData\-&gt;length, asciiStr \) == 0;
> \}
> 
> Are prolly performance critical to inline\.
> 
> ```

I wouldn't be too worried about (non-)inline performance implications, in general (and then, would prefer actual measurements over guesses anyway). Many of these "do more than just call the corresponding `extern "C"` function" cases resulted from the underlying C functionality not exactly providing the sought-after semantics (and the underlying C functionality having been deemed stable and unchangeable), and not necessarily from runtime performance observations.

> \* cplusplus bits in osl headers:
> 
> ```
> We still seem to have hybrid headers here:
> 
> ```
> 
> include/osl/time.h
> 
> #if defined \_\_cplusplus  
> struct TimeValue {  
> ...
> 
> ```
> Which \- I wonder \.\.\. is that necessary anymore ?
> 
> ```

With the same caveat as for the previous item, yes, include files that work in a C translation unit are probably no longer needed. (So for some `foo.h` and `foo.hxx` combos, they can presumably be combined into a single `foo.hxx`. For other cases, where the `foo.h` actually \*is\* "proper C++", the split had traditionally been done to avoid cyclic dependencies between `.hxx` include files, so some care might be necessary when cleaning such cases up.)

---

_[View the full topic](https://forum.collaboraonline.com/t/some-tweaks/5109)._