Version 6.5 as well as 7 do not seem to make much use of multiple threads, which makes the application cumbersome in many situations. For example, I have a lot of charts that for several reasons take an inordinate amount of time to load. I've got plenty of power to deal with the computational requirements, but I can only load and render one chart at a time. If I have 20 charts, for example, which isn't many, and they take 5 minutes each to finish rendering then my minimum time to get the workspace setup is 100 minutes, and that's if I'm monitoring the application continuously so that I input whatever change I might want to make. I otherwise like the application, but it's barely usable for me. Then if I want to make a change to an indicator, then I'll have to spend another 100 minutes to render the charts.
A separate thread should be spawned for each chart and opening a dialog box for one chart should not tie up the main application thread. I should be able to open the Data Series dialog box for every chart simultaneously, or open any other unrelated dialog box or menu option from an unrelated window, such as the Control Center. I would expect that the only window that relied on the the main application thread would be the Control Center, but as far as I can tell everything uses the main thread and holds hostage the rest of the application until it's finished doing its work.
Perhaps I'm overlooking a setting, feature or technique, which I would love to know about, but there otherwise is far too many operations running off of the main application thread. "Thread t = new Thread(); ....The .NET framework has tons of classes that make mulithreading a snap and the above is not meant to be a recommendation. There are many simple ways to have the framework start a new thread for some work and then release it to a pool when it's done. A rudimentary implementation would require only a few lines of code.
Have these techniques been considered?
By way of comparison, I have an account at Schwab, their StreetSmart Pro application is pretty out of date, but it is very, very responsive due to their generous use of multiple threads. I can fly through their maximum of 21 charts in about 15 seconds---as fast as I can type and move the mouse--entering symbols, mistyping a symbol and immediately or during load fix the typing error, access the menu while the chart is loading, perhaps even change a setting that affects the parameters of the current render, open any other window, menu, etc. They have tabs on their charts which enables one chart window to have many configurations readily accessible. Switching tabs might load the same or a different symbol with different parameters for the data series. Because of their use of threading, however, I can click each tab in sequence without a moment of hesitation, even though each click causes the chart window to reload. They also use chart configuration files (templates) that can be loaded from the chart window and while a chart is loading the current configuration, I can be accessing the menu on the same chart and using the file/open dialog to load a different configuration. I'm not suggesting any of these features beyond the use of multiple threads, necessarily. The equivalent of those features in NT would be if I changed the data series on a chart and then changed my mind and wanted to reopen the dialog box....but I first have to wait for my erroneous mouse-clicks to materialize in the form of the wrong chart configuration. And in the mean time, I can't do anything else.
In my opinion, I believe that the number one priority for the application should be threading and 6.5 functionality with intelligent use of threading would be a far better implementation than any future version without it.
Eric
A separate thread should be spawned for each chart and opening a dialog box for one chart should not tie up the main application thread. I should be able to open the Data Series dialog box for every chart simultaneously, or open any other unrelated dialog box or menu option from an unrelated window, such as the Control Center. I would expect that the only window that relied on the the main application thread would be the Control Center, but as far as I can tell everything uses the main thread and holds hostage the rest of the application until it's finished doing its work.
Perhaps I'm overlooking a setting, feature or technique, which I would love to know about, but there otherwise is far too many operations running off of the main application thread. "Thread t = new Thread(); ....The .NET framework has tons of classes that make mulithreading a snap and the above is not meant to be a recommendation. There are many simple ways to have the framework start a new thread for some work and then release it to a pool when it's done. A rudimentary implementation would require only a few lines of code.
Have these techniques been considered?
By way of comparison, I have an account at Schwab, their StreetSmart Pro application is pretty out of date, but it is very, very responsive due to their generous use of multiple threads. I can fly through their maximum of 21 charts in about 15 seconds---as fast as I can type and move the mouse--entering symbols, mistyping a symbol and immediately or during load fix the typing error, access the menu while the chart is loading, perhaps even change a setting that affects the parameters of the current render, open any other window, menu, etc. They have tabs on their charts which enables one chart window to have many configurations readily accessible. Switching tabs might load the same or a different symbol with different parameters for the data series. Because of their use of threading, however, I can click each tab in sequence without a moment of hesitation, even though each click causes the chart window to reload. They also use chart configuration files (templates) that can be loaded from the chart window and while a chart is loading the current configuration, I can be accessing the menu on the same chart and using the file/open dialog to load a different configuration. I'm not suggesting any of these features beyond the use of multiple threads, necessarily. The equivalent of those features in NT would be if I changed the data series on a chart and then changed my mind and wanted to reopen the dialog box....but I first have to wait for my erroneous mouse-clicks to materialize in the form of the wrong chart configuration. And in the mean time, I can't do anything else.
In my opinion, I believe that the number one priority for the application should be threading and 6.5 functionality with intelligent use of threading would be a far better implementation than any future version without it.
Eric
Comment