I have been thinking about ways to get the fastest code execution when one need it in Xojo without resorting to plugins or arcane coding tricks…
That was the impetus of my Freezable MemoryBlock request.
My GoTo thread reminded me of a feature in fortran I used back in teh stone age of computing … It was essentially a jump table… so I stated think of how could such a feature fit into the Xojo philosophy and this is the feature request I came up with:
<https://xojo.com/issue/56070>
In general Xojo has a reputation for being slow at certain things so that good performance for them can only be obtained from using plugs or som very non intuitive code
This is one suggestion to start adding features to help change that (another is 55820 - Enable freezing Memoryblocks enable making a mutable memoryblocks Immutable for processing)
The Xojo Select Case is very flexible and very readable but the flexibility limits its performance
Very often Select Case statements are used to select one option from a number of predefined ones say by an enum. There in that case all one needs is jump table.
From back when i learned fortran there used to be something called a computed GoTo What I am proposing here is essentially a structured computed goto…
It could look something like this:
JumpTo Case MyEnumVariable
Case Enum.member1
Some code
Case Enum.member2
Some code
Case Enum.member3
Some code
Else
Some code
End JumpTo
Under the hood Xojo could setup a jump table based an Enum values as the index into the table, What then could happen under the hood could be:
JumpToAddress AddressArray(Ctype(MyEnumValiable, Integer) )
If there is no case for that Enum member, it goes to the Else Address.
If an integer that is not in the enum definition was cast to the enum type, it could either go to the ELSE clause or throw an exception. (I would rather see it go to ELSE)
The execution of this should be blazing fast compared to a LONG select case statement. It would also be a lot less work (as well as more flexible) than settng up an array of delegates to do the same sort of thing
Please consider implementing something like this for cases when high performance is required and maybe we can can think of more such things that can be part of API 2.0 for situations when performance is paramount and the current features dont offer a good solution.
Thanks
-Karen