Menu Performance

Just recently I was debugging a security issue in an application menu when I came across something very interesting. When you click on a menu pad the SKIP FOR condition is evaluated on every menu item in the menu. Wow! This can be a pretty big performance hit if you have a bunch of complex SKIP FORs. It just so happens that a user reported a menu delay on a pretty slow machine that very same day.

VFE menu bars have an Allow method that checks to see if a menu item should be available. There are many things that could disable a menu and security level is one of them. The Allow method becomes the Skip For condition on the menu bar. The checking for security level was the thing that was really hurting menu performance. This code was going out to a table to retrieve the access level. The actual method code was efficient, just not running so many times. In addition, the menu’s security level is read and written to a property when the menu bar is instantiated. Therefore, it does need to be looked up each time unless the user’s access level has changed.

I was able to fix the performance problem with a very simple change to the base menu classes. This example applies directly to a Visual FoxExpress menu but the code can easily apply to any Visual FoxPro menu.

Here is what I did:

1. I added a property to my menu class called lRefreshSecurityLevelOnAllow.
2. In the Allow method, the code that tries to find the security level is wrapped in an IF lRefreshSecurityLevelOnAllow.

If I want the security level to be retrieved, I can simply set the menu property to .T. and the next time the code runs, the security level will be looked up in the table.

In the VFE menu class, this property is .F. by default so that all menus get the best performance. If you have code in your application that allows the user’s security level to change while the menu is active, you can set the property to .T. in order to refresh the menu and then turn it back to .F.