General code speed Xojo 64 bit vs RealStudio 32 bit

[Claes_Lundstrom]

@James_Sentman

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.

Will have a look. Thanks for the suggestion !

[Claes_Lundstrom]

I do understand your point. On the other hand, getting something done that is unique and different in so many ways, and that does what I need as a user is difficult. I see myself as a user much more than a programmer. It’s very much the basis of my consulting business.

[kevin_g]

I would definitely profile your RB and Xojo versions using Xcode Instruments as it should help to identify which of your methods are running slower and potentially the Xojo framework calls responsible.

[Claes_Lundstrom]

Tried both Moderate and Aggressive Optimization settings with no real change in speed compared to Default. Still stuck in the half as fast zone. I guess I have to dig into the details… You always hope there is some sort of magic button somewhere, but usually, there isn’t.

[Geoff_Perlman]

We find that rarely to be the case especially given the fact that speed wasn’t an issue in the past. I suspect that with some additional investigation, he will figure out where the performance problem is.

I think @James_Sentman is on to something with it being an encoding issue.

[Beatrix_Willius]

My app deals with GBs of data. I would have noticed when going from 32 to 64 bit if there was a problem with the encodings.

Have you looked at my blog series on Instruments?

[Andrea_Suraci]

Hi Claes! Based on my experience, I would try to optimise the code in a few key functions. What worked well for me and produced two-digit speed gains was:

• avoiding access to computed properties in loops, and in general trying to keep the call stack as short as possible;
• use doubles in graphics functions instead of using Round() to get integers;
• on Mac, perhaps setting the bitmap quality to low in CoreGraphics for screen refreshes.
• lots of clipping so that only the visible items are displayed.

[Claes_Lundstrom]

Hi Andrea, good to hear from you !
Thank’s for the input. I’m currently experimenting with timers to locate the slow parts. Luckily, I have a lots of paramedic settings for how things are displayed. So far, the underlying math seems to cope better that the drawing side. I can tell by reducing the stuff actually being drawn on the screen while maintaining the math structure underneath. As It’s a CAD program, it of course uses double math all over. I have tried rounding in the past an it did not make much of a difference. I do use clippings as much as I can, but it’s more difficult in 3D. So, still looking…

[Claes_Lundstrom]

After having analysed the problem, I have reached a very clear conclusion. The bottleneck is clearly in the way Xojo draws things. In the example model, the RS version did a full redraw in 0.271 seconds, whereas the Xojo 64 version did it in 0.621 seconds. I then removed all the drawing stuff except redrawing the picture used, while maintaining all the internal mechanical stuff. So it did everything except draw. The RS version did that in 0.189 seconds whereas the Xojo version did it in 0.131 seconds, in other words slightly quicker. What brought down the Xojo version badly was the screen drawing, using nearly 80% of the full drawing time. Just for reference, I also tested a 32 bit Xojo version, which behaved like the 64 bit, though a bit slower by say 10-15%.

[Claes_Lundstrom]

I tried a bigger model to see if there was any changes in the 70-80% proportions for the plain drawing vs the supporting grinding, and it was linear with the smaller model. The processing engine worked fine and was fast, but the final drawing was slow. It seems to affect all drawing objects too, like lines, rectangles, etc. I estimate that the bigger model contains around 100,000 objects, mostly lines but also some filled rectangles. The total drawing time was 0.900 seconds, where the supporting parts including building NURBS objects was 0.238 seconds. The RS version did a full redraw in 0.450 seconds. Did not dry run this model, but previous tests suggests that it would be about the same as the Xojo version or slightly slower.

As far as I can tell, there is not much I can do to improve this. Any suggestions ?

[Beatrix_Willius]

Did you try to do some profiling with Instruments?

[Markus_Winter]

That might be a really stupid question as I guess you know much more about graphics than I do and you are familiar with the technique, but have you tried drawing to a picture and just drawing the final picture on the canvas?

It can still be interactive and parts selectable)movable/changable etc.

[Claes_Lundstrom]

Of course I do. Should perhaps have said that. It’s much quicker than drawing directly. Was one of the first steps I did back in the stone age when the program made it’s first steps towards a working unit.

[Claes_Lundstrom]

Not had time yet. Not sure it would help in this case, as it’s so obvious where the bottle neck is, and where it’s out of our control for us as developers. What do you think?

[Beatrix_Willius]

Whenever I use Instruments I find something interesting. Perhaps you draw something x-times where 1 time is okay. Or you can cache something. And nothing is out of control for us developers. And usually it gives Christian something to do.

[Steve_Upton]

I’m a bit confused about your drawing.

At some point above you said that you used OpenGL but then you said Xojo’s drawing was slow…

Can you give more details about that?

[Claes_Lundstrom]

First of all it must be said that this is not a small utility program doing one or two things well. Its a large and complex program with many features and functions, and where many of are completely unique.

Yes, it uses OpenGL too for presenting models in a more photo realistic way, and for verifying that textures look good and are correctly located. This is however not the problem, as it works very well and it’s super fast.

It’s in the modelling area where Xojo is slow, more specifically when drawing things like lines and so on into a an image, which is then is drawn into an ordinary canvas. Each object can be displayed in a wealth of different ways depending on what it’s used for at any given time. Again, the underlying engine is fast considering what it does to reach a result ready for display on the screen. All objects are three dimensional, plus another two dimensions for unwrapped versions. Models are also updated dynamically as you edit the shapes and you can edit any number of control points in any number of panels at the same time giving you a superb shape control. All this of course depends of the model being updated quickly on the screen. The underlying drawing engine does an excellent job at this, and the RS studio also worked well in this respect. Xojo, on the other hand does the calculation as well as RS, but the simple task of drawing lines, rectangles, dots, etc. is where it’s very slow, for some reason.

[Greg_O_Lone]

Regardless, on modern versions of macOS, Windows and Linux, the pixel density of the screen needs to be added to the equation. For instance, with a retina screen either at 2x or 3x, the framework is drawing 4 or 9 times as many pixels respectively, so a speed difference is to be expected. The fact that macOS 10.14+ has a translucent interface slows things down a little bit more.

What I’m saying is that what you are seeing isn’t necessarily a Xojo framework issue, but may just be an underlying fact of working with modern OSs and high resolution screen.

Also, please remember that on Windows, users can set fractional scale factors like 125% . That makes the math even more challenging at times on make sure we’re not over or under drawing by a pixel.

[Markus_Winter]

@Greg_O_Lone

on modern versions of macOS, Windows and Linux, the pixel density of the screen needs to be added to the equation

As do more powerful graphics cards

As REAL.studio did not support Retina, but Xojo does (assuming you runs both on the same system and support for Retina is on in Xojo), what happens if you turn it off?

[Claes_Lundstrom]

The tests where actually performed on a fairly old (late 2012) 27 inch iMac running 10.13, so not much of Retina there in the first place. I will test it on a newer machine with higher resolution to see if makes a difference.

Greg, I can understand it being a little slower due to using more pixels etc, but on this old machine we are seeing a slow down factor of over six times. Does that make sense?