Working hypothesis for slow 6.0.1.2

[lhbaum]

I share the frustration of everyone re 6.0.1.2. with CPU maxing out and usability.

My hypothesis is that the problem is on the SERVER side and the problem involves the continuous futures contracts.

Question: Are the continuous contract's data assembled (concatenated) on the fly or are they pre-assembled in a database under their symbol? If done on the fly, the SERVER keeps every user's connection open while it concatenates all the months together. If all us 6.0.1.2 users have lots of continuous contracts in our workspaces AND the servers keep the connections open while concatenating, then you have a design problem that needs to be addressed. In other words, workspaces with no continuous contract symbols run faster than workspaces with continuous contracts. Would like to hear from everyone on this hypothesis.

Les

[ACM]

Les

Question: Are the continuous contract's data assembled (concatenated) on the fly or are they pre-assembled in a database under their symbol?

To my knowledge the data for a #F continuous contract is pre-assembled (to use your own convention) and stored on the server under its own symbol.
Alex

[lhbaum]

Working hypothesis for slow 6.0.1.2

What prompted my hypothesis was the noticable latency in the daily charts of #F continuous contracts compared to the 1 and 5 minute charts. Also, from time to time I see "looking up" messages on missing data fields in the quote sheets. Does the server time out or does it keep on a "looking up" thereby slowing everything else down which we see as a maxed out CPU while waiting??

Les


"To my knowledge the data for a #F continuous contract is pre-assembled (to use your own convention) and stored on the server under its own symbol. "
Alex

[ahhaha]

The problem isn't on the server side. It's on the client side in the exe. Doesn't do proper garbage collection. Each time you use a menu item or functional icon to run some analytical function the program invokes your command by creating a window's object. This object can collect data and retain it. If the object is used to derive another object, it can't be destroyed and neither can its data until the whole derived tableau is destructed. The only easy way to do this is to close the program and reopen. The program has to be rewritten to properly destroy objects after they're used. If one needs persistent objects, usually the case, this can be complicated.