Using a dylib function is really slow


I’m working again on a project that was put on hold for lack of time. It involves porting an Apple II emulator originally written in Java. I know, not very useful as there are already emulators that work properly. This is not a commercial project just for fun. It’s starting to work. It boots, the famous -151 call works and Applesoft programming also works. There’s still a lot to do, but I’m starting the optimization phase because Xojo isn’t exactly the right tool to do that. I’m using 2023r4. I’ve started by making a dylib to try to optimize the BitwiseAnd, BitwiseOr and others logical functions, which are called hundreds of thousands of times in just 1mn of operation. I just realized that going through my library was 10 times slower than using Xojo’s functions. When I disassemble the two, my function is much simpler and shorter than calling the Xojo framework. I deduce that it’s the call and return of the dylib function that creates the delay.

My question is: is there a way to speed things up?

Thanks in advance for your lights and advices

UInt16 xBitAnd(UInt16 v1, UInt16 v2)
     return v1 & v2;
       ; ================ B E G I N N I N G   O F   P R O C E D U R E ================

0000000000003e50         push       rbp
0000000000003e51         mov        rbp, rsp
0000000000003e54         mov        rax, rdi
0000000000003e57         and        rax, rsi
0000000000003e5a         pop        rbp
0000000000003e5b         ret
                        ; endp
0000000000003e5c         align      32

You’ve probably ran into a similar problem that Christian Schmitz reported about plugin calls having lots of unnecessary overhead.

My gut feeling is that you won’t be able to do anything about it.

Calling external function will never make sense to “optimize” small calls like a simple bitwise operation.

Probably. Innocently I thought after counting the number of cpu cycles taken by one or the other function that I was going to save a lot of time because for the moment the emulator is far from working at a correct speed.

If we had to rely on Xojo’s responsiveness … Another way would be to put the code directly into a memoryblock. I’ve seen this trick somewhere, maybe here.

Manually inline it since Xojo’s compiler wont do that for you.
DONT use a function for this & you’ll avoid the call overhead.

Compilers normally will do a lot of things like compute invariants in loops & hoist them out side the loop, inline functions, and unroll loops
You’ll have to do those for yourself

And make sure you turn off stack overflow checking, background tasks, nil object checks & bounds checking in the built version

Maybe I misunderstood but I don’t see how I could make logical operations without calling functions native or custom.

I can actually save a little time by doing this. Too bad there isn’t a directive to automatically inline a function each time it’s called.

For bitwise AND you and just use AND

    dim v as integer = 1 and 3

Same for OR and XOR

There are requests for it
Have been for some time
Lets just say that I dont expect this will happen any time soon without significant compiler work

even ordinary methods add a lot of overhead when called in a tight loop.
I just went through some of my code with a pragmatic eye…

Some variables had been set to computed - it was an easy way to ‘set some environmental stuff’ when a value was changed.
eg - change a property, 3 other properties get set to suitable values in the Set()

But that means that the Get () was a method, rather than using a simple property.
And it carries overheads… just whacking stuff in and out of the stack takes time.
I changed the property back to a normal property, and created a SetValue method for those times when I wanted the extra stuff to happen.
In some areas, that has halved the execution time of some tight loops.


AND, OR and XOR don’t do the job. They return a boolean instead a number. Emulating a processor requires, among other things, the ability to perform logical operations at the bit level.

I’m still looking for the trick of putting opcodes in a memory block and then invoking this code. I think I saw it on the official forum during a discussion about an x86 assembler made with Xojo. If anyone has a clue … at least to give a try.

I have one question: why not implementing it with java??? I can’t understand why there is a need for xojo especially while it is slow using dylibs. Using it with xojo Isa bad way to implement. Using Java will provide you the entire functionality of it. And you can write software around without problems


Var r, a, b As Integer
Var s As String 

a = &b1011011
b = &b1101001

r = a Or b
s = "a Or b" + EndOfLine + EndOfLine
s = s + a.ToBinary +" = " + a.ToString + EndOfLine
s = s + b.ToBinary +" = " + b.ToString + EndOfLine + EndOfLine
s = s + r.ToBinary +" = " + r.ToString + EndOfLine
MsgBox s

r = a And b
s = "a And b" + EndOfLine + EndOfLine
s = s + a.ToBinary +" = " + a.ToString + EndOfLine
s = s + b.ToBinary +" = " + b.ToString + EndOfLine + EndOfLine
s = s + r.ToBinary +" = " + r.ToString + EndOfLine
MsgBox s

r = a Xor b
s = "a Xor b" + EndOfLine + EndOfLine
s = s + a.ToBinary +" = " + a.ToString + EndOfLine
s = s + b.ToBinary +" = " + b.ToString + EndOfLine + EndOfLine
s = s + r.ToBinary +" = " + r.ToString + EndOfLine
MsgBox s

AND OR XOR etc on NUMERICAL values do BITWISE AND OR NOT with NO function call overhead
Try it

As mentioned in the first post this emulator is already written in Java.

I know like others people here that Xojo is far being the best tool to do this kind of thing but see that as a kind of challenge. To make a long story short, I’m retired. I spent over 24 years of my life at Apple, first as a technical support, then a programmer, then a network engineer and finally an IT manager. It’s just nostalgia and I like doing things that have no meaning or use and keep my mind busy. Anyway thanks for the suggestion :wink:

1 Like

So why even have the functions or ever use them?

  • Karen

I dont recall when the AND OR NOT XOR got added to handle numerics as well

So for a long time you had no choice but to use the functions

Looks like the first big compiler overhaul in 2006 ish might have changed this
LR from 2007 suggests AND had been modified to handle booleans & integer AND by then
So its not THAT new :stuck_out_tongue:
And there were still shift left & right operators that had no overload of something like AND OR NOT XOR etc do