Plugin Structure influence on loading and precompiling?

Does something know how the plugin structure influences the load and precompile time?

We have seen times change if we split or join plugins.
Not sure where the sweet spot is.

@William_Yu, could some time be saved, if you cache the dylibs written out from plugins, e.g. leave them in Caches folder? Seems like dlopen() on them takes long for code signature check and the system may cache the results if you don’t write new dylib files.

Also does the compiler precompile each declaration per loaded dylib on it’s own or does it pass all declarations from 20 dylibs in one plugin file to the compiler at once?

The most time consuming bit is not so much in the actual loading of the dylib, but more about parsing all the definitions/structures from there. That’s an area we can definitely improve upon…

Could you add some code to print times to Console/Terminal/debugview?

see
65050 - Have Xojo log when it starts/ends loading plugins
65051 - Have Xojo log when it starts/ends precompiling plugins

You can put all MBS Plugins in the plugins folder.

In Terminal set

MBSDEBUG=1

Then launch Xojo via Terminal:

/Applications/Xojo/Xojo.app/Contents/MacOS/Xojo

First entry from plugin shows 17:21:53.983 and last 17:26:02.190 for me. About 248 seconds on my MacBook Pro!

Precompiling is about 4.5 minutes.

When I unpack all plugins into folders instead of the zip, it is start time 18:33:00.350 and end time 18:34:21.674. this is just about 1:21 minutes, so much faster. Second run is just 20 seconds! Dylib did cache, I think.

Really guys. Maybe think about unpacking the zips once in temp folder and then reusing those files!

65053: cache dylibs for zip packaged plugins

Could you make another FR to cache the definitions/structures?

The .zip structure is for convenience, not a performance optimization by any means. You already have the option of distributing plugins using the folder structure instead.

You know, I don’t like using folders.
And we could speed it up, if you guys would cache the dylibs and have macOS don’t do a security/codesign check one each dylib each time.

2 Likes

We have three things

  • Xojo reading zip archive and writing dylibs
  • dlopen reading dylib
  • Plugin dylib initialization
  • Xojo parsing structures.

I think dlopen does much more checks compared to previous years, like notarization verification, code signing checks. And the link cache plays in here as second time the checks are not performed if the file didn’t change.

So we can benefit greatly if Xojo would not write the files to temp folder and delete later, but write them to cache folder. And then don’t delete them there, but on next time check if it’s the same file and don’t overwrite it, but reuse it.

1 Like