Custom workspace = slow HISE

[Christoph Hart]

@d-healey Hmm, this is already "cached" in the sense that it just parses a compressed value tree containing the docs and creates a C++ object containing the formatting which shouldn't take too long.

Can you investigate further? Maybe it's time for you to learn how to use a profiler to find hotspots - this should give you an exact call stack of the heaviest calls including where it spends the most time so we can pinpoint it down to the font hinting algorithm (my guess here). I think the main one in Linux is valgrind but I've never used it and I can imagine there is some Linux-style extra nerd layer applied to its workflow :)

EDIT: This looks like the tools I'm using on Windows / macOS and allows you to attach the profiler to a running HISE build, so it might be easier to get running.

[d.healey]

@Christoph-Hart Thanks, I'll take a look and report back

[d.healey]

Not exactly sure what I'm looking for but this stuff is eating some CPU when the API thingy isn't commented out.

[Christoph Hart]

@d-healey yup, looks font related (libfreetype seems to be the font library on Linux). Can you check the call stack for this call?

[d.healey]

[d.healey]

This post is deleted!

[d.healey]

Ah I think I finally worked out how to see some useful data. Does this help?

Digging further. It seems to be all these help. commands in CodeEditorApiBase.cpp

[Christoph Hart]

@d-healey it looks like it‘s not caching the fonts so it destroys them everytime…

[d.healey]

@Christoph-Hart Could this be related? https://forum.juce.com/t/slow-startup-due-to-font-enumeration/6864

[Christoph Hart]

@d-healey I've pushed a possible fix that might keep the fonts alive on Linux and avoid the reconstruction of the font every time it's used), but I can't test it and it might be possible that this doesn't affect anything, so please check if it helps.

[d.healey]

@Christoph-Hart Thanks. I'll give it a try now

[d.healey]

@Christoph-Hart Doesn't appear to have helped unfortunately. Just to confirm that it isn't something unique to my system I also tested in a virtual machine and it's the same.

[Christoph Hart]

Can you add the destructor to the LinuxFontHandler::Instance() class, then set a breakpoint in its body (at the bogus line) and check when it's called? It should stay alive during the entire lifetime of the HISE application:

HISE/hi_tools/Macros.h at 65fbb2e8cdbb2e365bfbb38186be259b8735f2c9 · christophhart/HISE

The open source framework for sample based instruments - HISE/hi_tools/Macros.h at 65fbb2e8cdbb2e365bfbb38186be259b8735f2c9 · christophhart/HISE

GitHub (github.com)

    ~Instance()
    {
        int x = 5;
    }

[d.healey]

@Christoph-Hart I'll give it a go after lunch and report back.

[d.healey]

The destructor is triggered every time GLOBAL_BOLD_FONT() is called.

[d.healey]

I tried replacing the defines with this, to cut out the extra class stuff:

#define GLOBAL_FONT() (Font(Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::oxygen_bold_ttf, HiBinaryData::FrontendBinaryData::oxygen_bold_ttfSize)).withHeight(13.0f))
#define GLOBAL_BOLD_FONT() (Font(Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::oxygen_regular_ttf, HiBinaryData::FrontendBinaryData::oxygen_regular_ttfSize)).withHeight(14.0f))
#define GLOBAL_MONOSPACE_FONT() (Font(Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::SourceCodeProRegular_otf, HiBinaryData::FrontendBinaryData::SourceCodeProRegular_otfSize)).withHeight(14.0f))
#define GLOBAL_BOLD_MONOSPACE_FONT() (Font(Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::SourceCodeProBold_otf, HiBinaryData::FrontendBinaryData::SourceCodeProBold_otfSize)).withHeight(14.0f))

And surprisingly it made a big improvement. I don't think it's as fast as on Windows/MacOS though. And all the fonts in the GUI have changed, so I probably broke something :p

Scriptnode also isn't lagging like crazy now, so I think that issue was related.

And HISE isn't crashing as much when switching between big projects! How I have waited for this day.

[d.healey]

@Christoph-Hart Any more suggestions for me to try?

[Christoph Hart]

@d-healey try again with the latest build...

[d.healey]

@Christoph-Hart No improvement unfortunately. But wouldn't you have to make some change in Macros.h too since the GLOBAL_FONT defines are still calling LinuxFontHandler::Instance()...?

[Christoph Hart]

@d-healey Yeah my hope was that if you construct one instance that is alive during the entire lifetime of the app that it will keep alive the shared data object that holds the fonts. See here:

JUCE: SharedResourcePointer< SharedObjectType > Class Template Reference

(docs.juce.com)

So the solution is definitely keeping this thing alive. On the other hand it's so long time ago that I've implemented the custom Linux solution that I forgot why it's there in the first place (a comment would be nice here). So maybe we have to think about an entirely different approach and the performance impact that it has on Linux should definitely be addressed. Maybe I need to dust off my linux distro and give it a shot as this requires some advanced debugging.