Speeding up Studio

If you are converting an existing Omnis Classic application to Omnis Studio you might be in for a surprise... your application will likely run slower in Omnis Studio than it did in Omnis Classic.

Studio gives you lots of neat new objects and features and it gives you an object-oriented programming development tool, but there is a price to pay.

This section provide information on things you can do in Omnis Studio to help your application run quicker.

If you know of additional things or have additional information please email me.

COMMENTS BY REG PALING (a snip from the List Server)

Occasionally in the past we've had a lister getting into a panic about performance of their new Studio app because they made a few design decisions which didn't work well on the first attempt, and with help from the list they've made a few adjustments and it has all been sweet.

So, with Studio you do have to design carefully to avoid creating structures that get bogged down in too many levels of processing. If you really need to create complexity, then don't be shy about demanding the fastest possible hardware to run it on. It's your choice as a designer: create simple structures and they will run fine on six-year-old hardware, or create complex structures which require a newer-generation machine.

For those who have simple applications, the conversion from O7 to Studio can be fairly easy. For those with complex applications in O7, think about how much time and effort you applied to fine-tuning your application, but then don't expect that same fine-tuning is going to work well in Omnis Studio - maybe the opposite, and you'll have to put in double effort to dismantle all that work and then re-do it.

Complex Grids

There have been complaints about the wave effect redraw of complex grids. You can do almost anything with a complex grid, but as the name states, they are complex. Each line of a complex grid is in effect a separate instance. A 100 line complex grid has 100 line instances. Each instance can have exceptions for each field inside of it.

I use complex grids whenever I want the user to be able to edit data directly in a list. (Purchase Order items, AR and AP Invoice items, etc.) Fortunately, the complex grids in my application are generally under 10-40 lines so I haven't hit the slow redraw wave effect that others complain about.

Max Cached Classes

In the Omnis Studio Preferences , there is a property $maxcachedclasses. I believe Omnis defaults it to 100. Bump it up to 200 or higher. You can experiment with different settings.

Before Omnis added this property my application would run slower and slower the longer I used it until finally I'd have to quit and restart Omnis Studio. If you find your application running slower the longer you run it ... there's a good chance you need to bump $maxcachedclasses up. To set this for runtime users I set it using notation in the main library's Startup_Task.

There is no clear answer on the best setting for this property. The default is 100. At the time of writing this tip I have set to 200 in the Startup_Task of my main library to make sure runtime users of my application are automatically set to 200.

Do $prefs.$maxcachedclasses.$assign(200)

Setting $maxcachedclasses to some wildly high number is not advisable as it could start to hamper performance.

Advice from Tech Support

Some developers have noticed that issuing $definefromsqlclass causes a sizeable performance hit.

At present we are unable to fully explain exactly what is happening here. Our thought is that this may be connected to class caching. In that the SQL classes are not in the cache and must be read from disk. This may mean that you need to adjust $prefs.$maxcachedclasses to remove this problem. We have not seen the problem and therefore this may not be the case.

I include the details on the sys functions that may be used to analyse the caching performance.

sys(190) returns the number of times Omnis has loaded a class from disk and added it to the memory class cache.

sys(191) returns the number of times Omnis deleted a memory class cache entry, when it added a
class to the cache, meaning that the class deleted from the cache may need to be reloaded.

OmnisSQL

The Omnis data file is a helpful SQL learning tool, it's free, and it works good, but don't expect it to work like Oracle, MySQL, or FrontBase.

OMNISSQL will bog down if you include too many arguments in your SQL select, include an ORDER BY, or try join too many tables.

Subwindows

If you load up a window with 100+ fields using tab panes and/or page panes opening the window will seem to take forever. The reason is that the Omnis Studio supports multiple window instances, superclass/subclass structure, a $construct for every field in the window, etc. All that neat object-oriented programming stuff comes at a price.

The solution I found is to use tab panes and page panes. Each layer of the tab/page pane has an empty subwindow field set to kEFposClient and the $classname left blank. Opening a window like this is very fast. :-)

Using notation you $assign the $classname for the tab/page panes only as the user requests to do so. So in reality tab/page pane 1 will have its $classname set when you open the window. When the user clicks on a different tab you intercept the click and set the $classname.

; $event method of tab pane with empty subwindows on each pane.
On evTabClicked
Switch pTabNumber
   Case 2
      Do $cinst.$objs.TabPane.$objs.SubWin2.$classname.$assign('wSubwindowNameB')
   Case 3
      Do $cinst.$objs.TabPane.$objs.SubWin2.$classname.$assign('wSubwindowNameC')
End Switch

StudioTips Documentation - Copyright 2006 Vencor Software