Improve Xojo Launch Time when using MBS?

Add-Ons
21

There are a few feedback cases for this. More caching, loading background, precompiling in background, etc.

1 Like
22

MBS_MacOSX_LaunchServices_Plugin

The plugin is MacOSX and the part inside that is LaunchServices.
As said, it may be good to wrap Mac only code with #if targetMacOS

23

How would the Windows builds successfully achieve to load a dll for a Mac OS-only call?

24

I would imagine they don’t. I believe the plugin exists as a stub for the other platforms so that code still compiles. The conditional compilation means the build wouldn’t even include the stub for the other platforms.

2 Likes
25

You’re right, and I know Christian answered this years ago (when this forum didn’t even exist and the mailing list was the current channel).
But I don’t see how surrounding code with “#if targetMacOS” would avoid more dll to be included/loaded in the Windows build, as he suggested in his post. That’s the reason of my question.
Thanks.

26

When the compiler goes through your code it also figures out what items are and are not used.
And if those are plugins then it knows to include the plugins DLL’s in the built app.
If the code is surrounded by #if TargetMacOS then that code will NOT be used or included in a Windows build and so anything that code depends on won’t be included.

The same is true for your Xojo code.

27

if you call e.g. folderitem.IsBundleMBS somewhere in code, the DLL for that function will be included, even the function doesn’t do anything.

See blog posts: Reducing app size with #if or Using dash if to reduce app size by referencing less plugins

28

Norman, that works for platform specific code, but what about the Plugin classes that the code depends upon? For example, I have an app which uses AVFoundation on macOS and DirectShow on Windows. I have class objects in my project for both platforms, and the plugins are included in the compiled versions for both platforms, even though all the plugin-specific code is surrounded by #If Target… #Endif.

The IDE allows specifying if classes are included in 32bit/64bit builds, and in Desktop/Web/iOS builds, but it doesn’t allow specifying the target OS in the “Include in” list.

29

You declare properties as variant to avoid the dependency.

30

…but that would mean that you loose all the autocomplete, parameter checking, etc. when creating code using for these classes. Sorry, don’t bother answering, this thread has already strayed far from its original topic of improving Xojo launch times and I’m not helping the situation :wink:

31

Of course, but the “TargetMacOS” condition won’t prevent “a second time” something that is already prevented by the fact that the plugin calls are Mac-only (stub), thus not added anyway.

32

Ah, ok. I didn’t know (nor expected) it…
Isn’t this a flaw of the compiler/linker?

And then, if the function does nothing, is it loaded anyway or just included?

Thank you.

33

The compiler has no idea if the calls are or are not macOS only (or windows only etc)
It only knows “this plugin exposes this class/method and that IS used so I have to include that plugins code”
If it IS meant to be macOS only then surround it with #if Target and that will make sure that the compiler doesnt try to include things it should not

34

Proxy objects

You interact with one main item and internally that one object instantiates an object specific to macOS or Windows or linux etc

35

I absolutely don’t use that function.
Or any of these:

:slight_smile:

I suspect that code in another plugin has its own reference to this stuff, and drags it along for the ride.

36

Maybe one of the classes?
I can’t know what the compiler sees for your project.

37

But, in the resulting app, plugin code that is only (say) Mac won’t obviously be present in a Windows executable (since the API doesn’t exist there), so at a certain point, it could notice the call is just blank, no?

38

No
Thats not how it figures things out
Even if the plugin method does nothing the call still can be made - it just does nothing

its the same as doing this in your own code

Sub foo()
      #if targetmacOS
      #else
            /// do some long involved work here
      #endif
End Sub


// somewhere else in your app it has

  Foo

the item that contains Foo cannot be eliminated even though on macOS foo will do nothing and is “empty”

However IF you had done

     // somewhere else in your app it has
    #if targetMacOS = false
          Foo
    endif

NOW the compiler will know that foo is NOT used at all in a macOS build, regardless of its contents, and could potentially eliminate the item that holds foo (maybe a module)

1 Like
39

I’d love to share the links to the few that I know about, but Feedback is totally FUBAR on Linux right now …

40

The compiler doesn’t know. The plugin will simply do nothing on Windows, but the functions are there to allow compilation. Your code may never call them. You can comment out MBS related calls and see if you can reduce number of Mac DLLs for Windows.

1 Like