Yes Paul, the crux is that requestTimedRefresh only has a 1 second resolution, whereas in the preferences you can set it to 0 for per tick updates, or as fast as your charts permit.
What I'm requesting only applies to the instance where you have it set to 0 in the preferences. Regards, Julian. --- In [email protected], "Paul Ho" <paul.t...@...> wrote: > > Julian > It does, but only if the refresh time interval is >= 10 seconds as well. > I do that all the time with my RT trading. I have trading logic that is > updated every 1 sec, and querying and displaying of my positions as a > separate chart, updating every 10 seconds. > If you put now() in your chart title, you can see how often your chart is > being refreshed. > > --- In [email protected], "Julian" <juliangoodsell@> wrote: > > > > Paul, > > > > the problem with requestTimedRefresh is that it doesn't remove that chart > > from the standard update queue. > > If I specify requestTimedRefresh(10), that chart is still going to be > > updated along with every other chart on every standard refresh, perhaps > > once a second, which is a waste of cpu time. > > > > What I want is for that chart to only update every 10 seconds so that other > > charts can be updated more quickly. > > > > Regards, > > Julian. > > > > --- In [email protected], "Paul Ho" <paul.tsho@> wrote: > > > > > > I'm not sure what you're trying to do. > > > It is already possible to specify how often to update charts > > > individually. The refresh rate in preference set the slowest rate and the > > > default refresh rate. Individual chart can be refreshed at a rate set by > > > requestTimedrefresh(). the only difference between what you want (I guess > > > ?) and what AB is doing seems to be one of the following > > > 1. requestedtimedrefresh does not guarantee refresh rate > > > 2. not possible to refresh more frequently than 1 second. > > > > > > Traditionally, A tick is defined as a minimum move in price that is > > > possible in an instrument. In AB, I gather a tick is both defined as a > > > course of sale as well as a 5 seconds interval,ie. 12 ticks a minute. So > > > I'm not sure what you mean by rendering every tick. But if you want to > > > render you charts for every new course of sale, then it is more possible. > > > Is that what you want? > > > > > > --- In [email protected], "Julian" <juliangoodsell@> wrote: > > > > > > > > Hi Tomasz, > > > > > > > > just to be clear from my side, as this thread has veered off course a > > > > little, I'm NOT suggesting running afl scripts without a render, or > > > > threading out the afl processing from the GDI rendering. > > > > I'm NOT suggesting any changes to the current architecture. > > > > > > > > I'm asking for the ability to set refresh rates per chart, for which > > > > the functionality already seems to be there. > > > > Running indicator calculations without rendering is a waste of cpu > > > > time, and so is rendering charts that don't need to be. > > > > If I have a chart that only needs to be updated every minute, there's > > > > no point in AB trying to render it on every tick update. > > > > > > > > Allowing us to specify at what intervals we want individual charts to > > > > update, would save countless wasted cpu time. > > > > > > > > Regards, > > > > Julian. > > > > > > > > --- In [email protected], "Tomasz Janeczko" <groups@> wrote: > > > > > > > > > > Hello, > > > > > > > > > > There is no sense in doing indicator calculation when this calculation > > > > > does not lead to actual rendering. That would be waste of CPU. > > > > > The purpose of doing indicator calculation is to actually display it > > > > > (refresh it). > > > > > Indicators formulas are here to display something. > > > > > > > > > > If you want code that does not display anything, you should run it as > > > > > automatic-analysis (scan/exploration) code. > > > > > > > > > > Also AFL formula execution is often much faster than final GDI output, > > > > > therefore even if AFL formula was executed in parallel, it would still > > > > > face GDI contention because of Windows GDI system-wide lock. > > > > > > > > > > Only on Windows 7 this system-wide GDI lock is removed and only > > > > > there you could see graphic performance scaling > > > > > > > > > > Again, read the entire article: > > > > > http://blogs.msdn.com/e7/archive/2009/04/25/engineering-windows-7-for-graphics-performance.aspx > > > > > > > > > > Especially figure 4 GDI Concurrency and Scalability > > > > > - as you can see in any pre-Win7 systems, GDI does not scale *at all* > > > > > with adding threads. > > > > > > > > > > I can ensure you that I have actually *timed* many scenarios > > > > > and what I say is based on actual measurement and not on somebody's > > > > > "belief". > > > > > That was one of the reasons I did not use GDI+ ("improvement" > > > > > suggested by somebody on this list) > > > > > because real-world test revealed that it is 6 times slower than > > > > > normal GDI. > > > > > Microsoft admitted that by the way in their recent demonstration on > > > > > PDC (prof. dev. conference). > > > > > > > > > > So, all decisions regarding development of AmiBroker are not based on > > > > > beliefs but on > > > > > hard code profiling evidence. > > > > > > > > > > Best regards, > > > > > Tomasz Janeczko > > > > > amibroker.com > > > > > ----- Original Message ----- > > > > > From: "Yofa" <jtoth100@> > > > > > To: <[email protected]> > > > > > Sent: Sunday, July 12, 2009 9:47 PM > > > > > Subject: Re: [amibroker] Per Chart Refresh Rates > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > >> Tomasz wrote in the "Data And PlugIn Speed" thread > > > > > >>I may add that the concept of independent rendering from multiple > > > > > >>threads > > > > > >>although attractive from first look, it inevitably hits the wall of > > > > > >>GDI > > > > > >>which in all current versions of Windows has > > > > > >> single system-wide exclusive global lock, which means that only > > > > > >> ONE thread > > > > > >> can actually render at one time. This means that adding threads > > > > > >> does not > > > > > >> give you better performance. > > > > > > > > > > > >>The truth is that all current releases of Windows are not > > > > > >>particularly > > > > > >>suited for multi-core/multi-CPU > > > > > >>but good news is that Microsoft apparently have given these > > > > > >>limitations > > > > > >>some thought and > > > > > >>many of them are removed in Windows 7. > > > > > > > > > > > > That is true for rendering only! (Apps main thread is allowed to > > > > > > write the > > > > > > GDI device. So rendering is limited to a single thread.) > > > > > > > > > > > > But indicator calculation (and trading logic) could get executed by > > > > > > any > > > > > > threads. Am I right? So doing the calculation on a background > > > > > > thread than > > > > > > doing chart painting with the "main" thread would increase > > > > > > processor usage > > > > > > and increase chart refresh reate? (I guess we all have dual and > > > > > > quad core > > > > > > CPUs...) > > > > > > > > > > > > How about separating "calculation refresh rate" and "chart refresh > > > > > > rate"? So > > > > > > I could request my panel to execute 3 times per sec without chart > > > > > > repaint > > > > > > (this could be executed by any threads) and refresh visible chart > > > > > > in every > > > > > > 3rd sec (this requires rendering, so calculation is done by a > > > > > > background > > > > > > thread, and painting is done by main thread))? > > > > > > > > > > > > Any thoughts? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Y > > > > > > > > > > > > (I know it is not doable in a day work, but I guess all short > > > > > > term/daytraders are having trouble bacause of refresh limitations.) > > > > > > > > > > > > > > > > > > -------------------------------------------------- > > > > > > From: "Julian" <juliangoodsell@> > > > > > > Sent: Sunday, July 12, 2009 8:14 PM > > > > > > To: <[email protected]> > > > > > > Subject: [amibroker] Per Chart Refresh Rates > > > > > > > > > > > >> Hi Tomasz, I thought I'd start a new thread on this topic as I > > > > > >> think it's > > > > > >> an interesting one. > > > > > >> > > > > > >> Tomasz wrote in the "Data And PlugIn Speed" thread > > > > > >>> I may add that the concept of independent rendering from multiple > > > > > >>> threads > > > > > >>> although attractive from first look, it inevitably hits the wall > > > > > >>> of GDI > > > > > >>> which in all current versions of Windows has > > > > > >> single system-wide exclusive global lock, which means that only > > > > > >> ONE thread > > > > > >> can actually render at one time. This means that adding threads > > > > > >> does not > > > > > >> give you better performance. > > > > > >> > > > > > >> In response to that Tomasz, > > > > > >> you're referring to performance on the basis of multiple charts > > > > > >> being > > > > > >> rendered per refresh update. > > > > > >> E.g. If you have ten charts on screen, and they take a total of 2 > > > > > >> seconds > > > > > >> to render, then there's little performance gain to be had by > > > > > >> threading > > > > > >> them because of the GDI lock. That is fine and I get that. > > > > > >> > > > > > >> But what I'm referring to is the ability to control which charts > > > > > >> render > > > > > >> when, so that all ten don't have to be updated every refresh. > > > > > >> The problem is that in real time mode with the refresh interval > > > > > >> set to 0 > > > > > >> in the preferences, if I have a tick chart that only takes 10ms to > > > > > >> update, > > > > > >> it's still only going to be rendered every 2 seconds because > > > > > >> that's how > > > > > >> long the other nine charts take to render, even though I don't > > > > > >> need them > > > > > >> to be updated multiple times per second, but maybe only once every > > > > > >> 5 > > > > > >> seconds or even every minute. > > > > > >> > > > > > >> If we could set refresh rates per chart, then you could have time > > > > > >> critical > > > > > >> tick charts update as fast as possible, and longer timeframe or > > > > > >> more time > > > > > >> expensive/less critical charts only update every 5 seconds or even > > > > > >> longer. > > > > > >> > > > > > >> By staggering chart updates, traders would have much greater > > > > > >> control over > > > > > >> performance and not waste so much processing power updating charts > > > > > >> that > > > > > >> don't need to be. This would trounce any other kind of performance > > > > > >> improvement that could be gained by optimizing the rendering > > > > > >> engine > > > > > >> itself, and would require no threading or any real change to the > > > > > >> current > > > > > >> architecture that I can see. > > > > > >> > > > > > >> Moreover, it appears this functionality is already in AB, but just > > > > > >> that > > > > > >> there's no way for the user to control it. > > > > > >> The requestTimedRefresh() function enables you to update only the > > > > > >> chart it > > > > > >> is applied to, so they can obviously be rendered independently of > > > > > >> each > > > > > >> other. > > > > > >> > > > > > >> The problem though is that it is not enforceable. If I specify a > > > > > >> refresh > > > > > >> interval of 1 in the preferences, and then requestTimedRefresh(10) > > > > > >> on a > > > > > >> chart, that chart still gets updated every second along with all > > > > > >> the > > > > > >> others, and then once more after ten seconds. > > > > > >> > > > > > >> Giving the option to make requestTimedRefresh() enforceable would > > > > > >> be one > > > > > >> way of enabling this functionality. Perhaps add an enforceable > > > > > >> parameter > > > > > >> to the function like: > > > > > >> requestTimedRefresh(10, onlyvisible=True, enforceable=false). > > > > > >> Then if I specify requestTimedRefresh(10, true, true), that chart > > > > > >> should > > > > > >> only update every 10 seconds, irrespective of what I've set in the > > > > > >> preferences. > > > > > >> > > > > > >> Would this be as easy to implement as I think it is? If so, I > > > > > >> think the > > > > > >> benefits would be rather large. > > > > > >> > > > > > >> Jules. > > > > > >> > > > > > >> > > > > > >> > > > > > >> ------------------------------------ > > > > > >> > > > > > >> **** IMPORTANT PLEASE READ **** > > > > > >> This group is for the discussion between users only. > > > > > >> This is *NOT* technical support channel. > > > > > >> > > > > > >> TO GET TECHNICAL SUPPORT send an e-mail directly to > > > > > >> SUPPORT {at} amibroker.com > > > > > >> > > > > > >> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at > > > > > >> http://www.amibroker.com/feedback/ > > > > > >> (submissions sent via other channels won't be considered) > > > > > >> > > > > > >> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > > > > > >> http://www.amibroker.com/devlog/ > > > > > >> > > > > > >> Yahoo! Groups Links > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > ------------------------------------ > > > > > > > > > > > > **** IMPORTANT PLEASE READ **** > > > > > > This group is for the discussion between users only. > > > > > > This is *NOT* technical support channel. > > > > > > > > > > > > TO GET TECHNICAL SUPPORT send an e-mail directly to > > > > > > SUPPORT {at} amibroker.com > > > > > > > > > > > > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at > > > > > > http://www.amibroker.com/feedback/ > > > > > > (submissions sent via other channels won't be considered) > > > > > > > > > > > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > > > > > > http://www.amibroker.com/devlog/ > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
