Concerns about Speed

I have 2 areas of concern over the speed of the GUI.

My application is MDI subroutine and yes I do use, extensively, TAB Controls. I prefer to have all related data on one open form rather than popping up each page/tab as requested, although I can see how this will improve performance but it kind of defeats the object of having tab controls.

I've seen other windows applications with a similar number of controls and they load instantaneously. 

Hi Jeanette

Hi Peter

Speed is very important to us. We are battling the same issues as are shown in this thread.

Our template file has more than 1200 items and we use the MDI approach. So our application is very large.

We don't have a good answer yet on cache or anything else. We are in the middle of several implementations right now, so we have not had the time to post to this forum as we would like.

Hopefully, we'll all be back at the office next week and we will summarize our input.

Hi All -

I am posting this message so that we all understand how the GUI runtime actually works.

Basically, the application program on the host creates a command record, which is structured as a dynamic array, using the ATGUI... subroutines. This record is sent to AccuTerm using a normal BASIC PRINT statement. AccuTerm uses COM (OLE) to forward the command record to the GUI runtime process (ATGUISVR.EXE), which processes the record and executes the commands. Responses from the commands are packaged into a response record (also a dynamic array), which is sent back to AccuTerm and transmitted to the host. The retrieves the results using normal BASIC INPUT statements.

The GUI runtime process creates application, form and control objects in response to commands from the application. The GUI objects are implemented in VB as a private Class that wraps a real VB6 form or control. The forms are generic, containing a hidden instance of each kind of control that is available to the GUI application. New instances of these controls are created and destroyed on the fly using a VB6 control array.

When you use a macro or template created by the GUI designer, the command record contains instructions to create all of the objects contained in the macro or template, and assign initial values for properties. ATGUIRUNMACRO sends the command record to the runtime, and returns the results. If the macro ID argument to ATGUIBEGINMACRO is not null, the ID is used as a cache ID for storing the macro on the local PC. ATGUIBEGINMACRO adds a time-date stamp to the macro for managing the cache (the GUI designer does the same thing for templates). When you call ATGUIRUNMACRO with a macro that has an ID, the command record initially only contains the ID and time-date stamp. When the runtime processes this record, it attempts to read the macro from the local cache on the PC and if the time-date stamp matches, it proceeds to execute the commands read from the cache. Otherwise it returns a failure status, and ATGUIRUNMACRO sends the entire macro. The runtime then updates the local cache and executes the commands.

The use of the cache reduces the amount of network traffic and the size of the message that is passed between Windows processes on the PC. However, only the commands to create and initialize the GUI objects are stored in the cache. The objects themselves are re-created when the cached commands are processed.

I believe that in the case of very large macros, the delay everyone is noticing is due to the (re-)creation of the GUI objects. I think fundamentally, this is a limitation of the implementation of the GUI runtime in VB6. At the present time there is not much that can be done about this.

However, in the future, we are looking at other environments for implementing the GUI runtime. If anyone was at the last Spectrum show, you might have noticed a simple GUI program running in FireFox in Linux. This was accomplished using a rudimentary implementation of the GUI runtime in Flex (Flash). So at least in concept, it is feasible to implement the runtime in other languages / environemnts. We are also exploring a C++ implementation.

So, for now, I think all that can be done is to use clever tricks to maximize the use of the cache mechanism, and manage the creation and deletion of forms, so that you only create forms as needed and do not delete them if they might be used again. In this case, you must be careful not to leave "too many" objects loaded, to keep from running out of memory on the PC. I'm not sure what the correct number is for "too many", but there is another thread on this forum with some thoughts about this.

In case anyone feels adventurous, try installing the debugging version of AccuTerm, and run asdebuglog.exe to trace the GUI server engine. There are several trace options you can select for atguisvr - please experiment.

I hope this helps with understanding the inner workings of the environment.

Thanks,

Pete

Hi Calidore -

One way to confirm this is to use the built-in cache. If the cache is valid, then the host only sends the macro ID and time-date stamp, probably less than 100 bytes. Run the application two times, timing the 2nd run, which should use the cache. Then delete all the files in the c:\program files\atwin\tmpcache and run the application again. Since the cache is now empty, the entire form definition will be sent from the host. This should give a fair approximation of the time required for sending the complete macro accross the wire (and from the AccuTerm process to the ATGUISVR.EXE process). The time measured in the 2nd case will also include an extra round-trip transaction with small messages. To validate the cache, ATGUIRUNMACRO will send only the ID and time-date stamp first, then it will get a response indicating that the cache is invalid, after which it will send the complete macro.

Thanks,

Pete