I’m in the middle of converting a fairly advanced older 32 bit graphics program from RealStudio 32 bit to Xojo 64 bit using the current version (for the Mac), and I noted that the code is generally slower by a factor of two in most tasks. Is this what to expect ?
What does your code?
Please note that with HiDPI you are moving 4 times as much pixels for graphics.
I find that resizing takes longer.
As an example, in a tile-based application, if I have tiles of size 64 x 64 , but draw them at 32x32, its slow
If I create a set of 32 x 32 tiles before drawing , and draw them 1 - to -1 , the speed goes back up.
retina slows stuff down. Antialias slows stuff down
Pre-calculating is the way to go.
And yes, every year things get bigger and slower in ways that fancy new intel chips do nothing much to mitigate.
It’s an advanced 3D modelling program, heavily relying on calculating and screen drawing speed. 
1 Like
It doesn’t use Xojo open GL for modelling as this program is all about dynamic super precise shape control and updates during modelling. For rendering, it does use OpenGL though not the generic type. The speed of that is however not a problem as such, as the speed there is fine.
The sailboat example, in wireframe mode, contains 326 NURBS surfaces controlled by 13219 control points, redraws and recalculates the model shape dynamically in 0.654 seconds on the Xojo 64 version and in 0.302 seconds on the RealStudio 32 version. This medium sized /complex model therefore has a very clearly noticeable difference in speed. On bigger models, the difference is irritating. Some parts have an OK speed, whereas other parts are surprisingly slow. A simple save, for example, takes way longer than it does on the older version.
1 Like
Since this is highly mathematic, have you tried compiling with Optimization set to Moderate or Aggressive?
1 Like
Have you tried performing a time profile using Xcode Instruments as that might help you identify what has become slower.
Still in the early stages of this, so I haven’t done much optimisation yet. The original code has been subject to massive optimisation though over the years. Very often, you can find stuff that slow things down for no apparent reason, and where doing the same thing differently can make a huge difference. Therefore, it could very well be areas where the older program performed better, but where the new version lags severely. My initial question was mostly to hear from others whether this is a general trend, or if it’s likely that something bad happens in the new code. In this program, speed is everything.
I would definitely try building with code optimization and see what that does to performance.
Thanks for the suggestions. Tried Moderate optimization, which didn’t do anything in terms of speed. It made the app smaller but not faster. Trying Aggressive now, but it’s been at it for ages, so I’m not if it just got stuck on something. How long is it supposed to take? It’s a fairly large program.
It can take a while.
It get take a good long while. It will eventually finish.
It can take hours!
1 Like
I don’t know if this has anything to do with anything, but one thing that can be much slower now days than it was in the past it is string handling due to the built in encoding handling. Especially if the encoding isnt known. If you’re doing instr or doing any string matching or comparisons without setting text encodings or without enforcing them to be known that can be quite a bit slower. It doesn’t seem obvious that you’d be doing any of that in such an app during the rendering phase, but it’s something to think about. If you’re creating lots and lots of integers then they might be twice the size to pass around in memory in a 64 bit app than a 32 bit one. But you’d have to be creating many such things for it to make any difference at all. I know there are other things that are more costly now days than back in the 32 bit RealStudio days that have nothing to do with OpenGL but can be worked around. You might need to do some profiling at a finer grain than what you’ve shared so far to find out where the actual bottleneck is so we can better help narrow it down. It is also not impossible that something done as an optimization in the code for a 32 bit target is actually causing it to run much slower when in a 64 bit app. It might also be some of the 3D resources that are in a format that needs to be translated every time it’s used now where it was in the native format originally. There are so many possibilities but you might need to do some profiling just saving off the ms at start and finish of some logical blocks of the code to see what is really taking the longest so you know where to concentrate the effort and continue to narrow it down.
If Profiling identifies a method or two as being particularly slow, post the code here so we can offer suggestions.
Also, are you testing in the IDE or compiled? The latter will be significantly faster.
Edit: This reply was to James, but really meant for @Claes_Lundstrom.
1 Like
OK will let it go then. Wasn’t sure what to expect in time. Moderate took a while too but not that much longer than Default .
I have spent a lot of time analysing the code in substantial in the past (for 32 bit). Suspect that the speed has doubled or trippled over the years, easily. Tried rephrasing virtually all parts in great detail to get to to work faster. Realised that one way of doing sometimes works better than another for no apparent reason to me as a user. Since this is a completely different animal under the hood, I would not be surprised if something that worked very well in 32 bit may not be a good idea in 64 bit.
No, I always use a compiled version as it’s a big and complex program.
I have a series on Instruments on my blog at https://www.mothsoftware.com/blog/blog.php?search=instruments . Instruments can give you some hints why your app is slower.
2 Likes
Side note:
Not that you will like to hear this but for such a project, Xojo isn’t just what you need.