|
PureBytes Links
Trading Reference Links
|
> I am sorry to say this but this thread is just waste of time.
It wasn't a waste of time to me..... it all depends on our individual reasons for joining in the discussion.
As far as I am concerned the forum did me a big favour by filling in some of the missing parts of my AB education.
Once again, thanks to the contributors.
>features you are discussing now were planned 3 years ago long before
> you knew AmiBroker exists. Moreover they are on the Feedback Center >for years already (if somebody bother to check already
> submitted things).
I learn a lot more about the 'typical' suggestion by discussing them in the forum compared to reading the one or two line description at the FC.
--- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> wrote:
>
> Hello,
>
> I am sorry to say this but this thread is just waste of time.
> You may discuss things to death yet it has zero result in terms of program itself.
> Naive views/opinions/beliefs from most participants of this thread are pretty much do not have any impact on development of
> AmiBroker
> simply because development plans are made many years ahead and features you are discussing now were planned 3 years ago long before
> you knew AmiBroker exists. Moreover they are on the Feedback Center for years already (if somebody bother to check already
> submitted things).
> In contrast to cheap forum talk, the program development does not occur overnight. If you think that you will
> talk for a month about some feature and it will arrive just because you talked a lot you are wrong.
> There are zillions of things (half of them are not technical at all) that decide when and what way given thing is implemented
> and you are not aware of 90% of them.
> So my advice is to stick to trading and leave the development to me.
>
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "brian_z111" <brian_z111@xxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Tuesday, July 14, 2009 5:12 AM
> Subject: [amibroker] Re: Per Chart Refresh Rates
>
>
> > The intention of the mother thread,"Data and PlugIn Speed", was to focus on AB's RT Performance, as opposed to its capabilities as
> > a Backtesting Engine.
> >
> > For me this was an educational post and IMO the discussion has progressed nicely, across threads, with contrasting emphasis on
> > speculative ideas, on one hand, and hard-nosed critique, accompanied by factual observations, on the other ... it is quite OK with
> > me if others see the topics in a different way. or pursue other objectives/sub-objectives within them.
> >
> > To me it was always just a discussion, and not intended to be specifically critical of AB, or Tomasz, while at the sametime being
> > pertinent enough to have value.
> >
> > IMO opinion using the forum as a sounding board, which provides users with the opportunity to sound off, pool our factual evidence
> > and make critical assessents, prior to filing formal suggestions, is the best model for introducing progressive ideas that we
> > have.
> >
> > (As a rule of thumb, we need to sound off on them several times before they start to sound reasonable to the majority).
> >
> > Keep in mind that only a fraction of the discussion will end up as a formal suggestion and that only a small % of filed
> > suggestions will ever be implemented (especially in their original format).
> >
> >
> >
> > Re RT Performance versus Backtesting Performance:
> >
> > Irrespective of what AB's BT can, or can not, do, the reality is, that for one reason or another, many of us do use it as dual
> > software i.e. we do use AB as both a BT and trading platform software.
> >
> > Note that Janhaus said that he does not, and will not, use AB for high frequency trading, however, his objectives and situation
> > (budget/ skills/hardware) are most likely unique compared to the AB user norm.
> >
> >
> > From the discussion, so far, it seems that RT users:
> >
> > - want a trading platform type window with different behaviour to the other windows
> > - use a dedicated machine for RT trading (or close all other programs while RT trading)
> > - if they want to run extras, while running AB in RT mode the preference would be for additional monitors (go MS, go!)
> > - use of machines with MCP's is standard (number of cores vary!) ... multicore is now standard for midrange off the shelf
> > desktops?
> > - they are prepared to buy machines, use OS etc that are particularly suited to AB use
> > - consider that CPU useage is a critical issue ... consequently they want control over GDI workflow and CPU workflow
> > - they are well informed about performance issues and typically limit indicator code and symbols traded as a trade off to gain CPU
> > time to drive their 'trading platform' processes.
> > - they are well informed about and want control over the amount of data processed i.e. they want execution flow control
> > - they don't want to have to reference AA ... this is seen as being irrelavent when RT trading (either they are correct or some
> > intense education is required to change this view).
> >
> >
> > Speculating further, without any social or practical constraints in place (in order to learn some more or perhaps unearth some new
> > issues or possibilities):
> >
> > - spread trading is the most extreme trading that we could consider (one person in this forum has already indicated that this is a
> > strategy they are following, albeit not with AB as the software)
> > - bid/ask and tick arrival can be considered micro-events, compared to compressed data e.g sec or minute bars etc.
> > - microevents are dynamic, in time, and therefore need to be handled dynamically (indicators might need to be dynamic and not use
> > any lookback data at all?)
> > - it isn't practical for me (at this stage) because MarketMarkets play the spread without any frictional costs and they are
> > sitting on top of the markets with highspeed gear (compared to myself only)
> > - it might not ever be practical for the majority of traders to trade microevents OR trade them via AB .... however, like
> > AB/Tomasz, I want to gather some evidence from real world testing, to find out for myself, and not rely on others beliefs about
> > whether it is viable or not.
> >
> >
> > Hypothetically to BT bid/ask scenarios:
> >
> > - bid/ask data without volume at the bid ask is of lessor value therefore to Backtest some bid/ask indicators I will need a BT
> > with fields/functions that accommodate bid/ask and volume at the bid/ask at the least (full market depth history would be required
> > to fully test all possible strategies)
> > - possibly historical bid/ask data could be collected, by my software, when I am not actively enaged in RT trading OR perhaps I
> > could buy some historical data OR alternatively I could rely on live paper trading, using only a small number of recent bid/asks
> > etc and then only save the tradeSeries/calculated indicators for historical reference
> > - in any case, leaving aside the issues of collecting/managing the extreme amount of bid/ask data generated in a single days
> > trading and assuming that testing has been managed somehow and that I have a valid bid/ask system I want to implement.
> >
> > (Perhaps that aspect requires a separate thread).
> >
> >
> >
> > Hypothetically for RT spread type trading:
> >
> > - I would need the arrival of the a new bid/ask to be an actionable event ... down to the time limits of processing etc where
> > execution would revert to minimum ontime basis if the number of bid/asks that arrive exceeds processing capabilities i.e.
> > automatically execution of the bid/ask calcs would have to resort to a time absis in extreme high volume?
> >
> > - I would not want to see every 'behind the scene' bid/ask calc (is it likely that the MarketMakers, who set the spread, are
> > visually looking at every incoming bid/ask OR would they algorithmically make/take the bid/asks and only PHYSICALLY watch a
> > summary of the process instead?) .... I assume that in order to play this game I could physically look at every event when looking
> > at historical data in the BT but that for RT trading I would have to handover to my faster AT computer when in trading mode.
> >
> > - so, I would elect to AT the high frequency bid/ask indicators and only render actual trades entered, or orders placed etc, in a
> > window that needs to be refreshed i.e. I would only physically watch timed reports on my key performance indicators /trouble
> > shooting status etc.
> >
> >
> > Hypothetically .....what would I require of my software to be able to trade the spread:
> >
> >
> > (... thinking as a layperson ... first pass/draft version only)
> >
> >
> > - everything would have to be optimized to extreme levels to achieve this extreme performance
> > - I would need finer control of what constitutes an event e.g. arrival of a bid/ask or a tick is far more important than user
> > action e.g scrolling, so new bid/ask or tick quotes would need to be recorded as an actionable event in the fastest possible way
> > - I would need bid/ask calculations threaded out (almost certainly to another core?) and worked in the background (no visual
> > reporting of most of this)
> > - I would need a 'trading platform' type window, or windows, to provide me with the absolute bare min of updated reports from the
> > algorithmic trading that is going on in the background
> >
> > (I would need the training and mindset to go with this style of trading .... it is just like the difference in flying a high
> > performance aircraft, with only virtual feedback available, and flying a hobby aircraft by looking out the window).
> >
> > - I would have to forgo 'historical saving' of bid/ask data .. even data used on the fly might have to be progressively dumped as
> > new data comes in (challenging to find ways to keep it all for the session if we want to do what if checks at the end of the day
> > ... unless of course MCP somehow 'saves the day' in this regard).
> >
> > - I would need control over when a particular window refreshes and what drives the refresh e.g. refresh actions would need to be
> > parameter driven .... by default all parameters would be included (as in AB at present) but the user would elect what refresh
> > actions to turn off for any particular chart (all turned off,except for slow timed refresh would == something similar to
> > commentary? ... it would just give us a, say, 10 sec update on the score == W/L, PayOffratio, open trades, net gain etc)...... in
> > effect, a window with most actions/events disabled would function just like a static graphic (the keypoint is that users should be
> > able to define this, or graduations of it, for themselves).
> >
> > - I would need fine grain/extreme control over how much data to process at any time/for any event.
> >
> >
> > Realistically:
> >
> > - can AB achieve this?
> > - is it desireable for AB to achieve this?
> > - should AB keep its focus on being a cutting edge BackTesting engine, with some secondary RT charting that is only intended to
> > supplement design and testing efforts, and leave RT high frequency trading to other software?
> > - at the least, shouldn't AB allow us to somehow create an extreme event database and do our testing within AB ... and do this
> > with off the shelf features, so that it is accessable to all?
> > - perhaps thinking about how AB could hyptothetically trade microevents, in RT, will lead to some realisitic options that will end
> > up being implemented by AB, for use at subsecond timeframes (not necessarily bid/ask trading).
> >
> >
> >
> > KEYWORDS
> >
> > OPTIMAL RT PERFORMANCE
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
> >>
> >> > I just believe you'll get better support for what you're asking >within the realm of tick by tick trading.
> >>
> >> I agree that the issue is best considered in the context of bid/ask OR tick trading ... hypothetically considering those
> >> propositions is where we can learn the most about where we are, where we would like to go and whether, or not, we can
> >> realisitically expect to get to any of those places (more on this in another post).
> >>
> >>
> >>
> >> > May be Tomasz will implement it as it is for you, best of luck.
> >>
> >> IMO the arguments put forward by Julian, and supported by Dennis and Yofa, are compelling i.e.
> >>
> >> it is not an issue of scaling up, via application of new MS GDI features but rather one of taking the load off the GDI by
> >> removing unnecessary graphic rendering from the queue (some people seemed to mis-read Julians suggestion and kept going back to
> >> the GDI multithreading argument ... bottlenecking at the GDI is the argument that makes Julians case, rather than breaks it!)
> >>
> >> The second compelling argument, made by the proactive group, is that threading out background tasks, calculations etc from
> >> graphic rendering tasks can lead to RT improvement.
> >>
> >> I accept this generic argument (in fact I naively guessed at it myself a way back at the MultiCoreProcessing discussions) ....
> >> what I am not sure about is how it could apply in specific cases e.g. on a particular machine, where machines can have different
> >> OS and cores OR within AB in general, where the priority of subtasks could be user defined.
> >>
> >> Against this you posted the third most telling point of the discussion so far (in the top three points somewhere) when you
> >> highlighted the fact that AB only stamps bars down to a resolution of 5 secs ... I agree all RT performance theorising etc stops
> >> at that point, like a car hitting a 10ft thick concrete wall.
> >>
> >> At the end of the day, only Tomasz can make structural changes while we are left with the power to chose from the cards we are
> >> holding in our hands.
> >>
> >> >BTW with a few lines of C/C++ using windows timer you can implement >your own suppressedrefresh function which will do exactly
> >> >what you >want.
> >>
> >> Sounds like an idea worthy of further investigation.
> >> Probably a bridge to far for me at this stage ... maybe in a year or two.
> >> In the meantime the discussion on how to bring this to the people, via AB features, is a good one.
> >>
> >> Thanks for your good pragmatic contributions.
> >>
> >> --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> >> >
> >> > I just believe you'll get better support for what you're asking within the realm of tick by tick trading. May be Tomasz will
> >> > implement it as it is for you, best of luck. BTW with a few lines of C/C++ using windows timer you can implement your own
> >> > suppressedrefresh function which will do exactly what you want.
> >> >
> >> > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> >> > >
> >> > > Yes, I partially agree with you Paul,
> >> > >
> >> > > however just because some traders might see a feature as unnecessary and can't see a use for it, doesn't make it so or mean
> >> > > there isn't one. GetRTData and automatic trade entries are an example where sub-second updates could be useful.
> >> > >
> >> > > The fact that Tomasz has actually implemented a per tick update option means it must have been useful to some, unless he did
> >> > > it for fun. :) The problem is simply that this resolution is not available via requestTimedRefresh.
> >> > >
> >> > > Whether this feature is only useful to a minority of traders or not, it's such a simple (supposedly) fix, for a feature that
> >> > > is already supported, but is hindered in practice.
> >> > >
> >> > > Regards,
> >> > > Julian.
> >> > >
> >> > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> >> > > >
> >> > > > As long as the restiction on the resolution of timestamping of price data is set at 5 sec. There is no point in trying to
> >> > > > RT trade at tick level. As the requirement of unique time stamp is waived in storing tick data. tick database often gets
> >> > > > corrupted, ie., later db records can have older time stamp. And together without knowing the exact timing of these ticks
> >> > > > coming in. I dont believe there is anyone who is willing to trade with REAL MONEY at tick level.
> >> > > > From a practical standpoint, I have never found this refresh rate striction difficult to live with. A resolution of 1
> >> > > > second is plenty fast enough for me, even for trading futures.
> >> > > > I think Tomasz is thinking about rehashing the underlining db structure. Along with changing Volume to a floating point
> >> > > > number. if he would consider expanding his PackDate to more than 4 bytes. He can then have a timestamp resolution of a
> >> > > > fraction of a second. Then any request to enhance tick trading would make more sense. In the meantime. there isnt much
> >> > > > point in trying to get a faster refresh rate than 1 second IMHO.
> >> > > >
> >> > > > amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> >> > > > >
> >> > > > > 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 amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> 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 amibroker@xxxxxxxxxxxxxxx, "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 amibroker@xxxxxxxxxxxxxxx, "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 amibroker@xxxxxxxxxxxxxxx, "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 amibroker@xxxxxxxxxxxxxxx, "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: <amibroker@xxxxxxxxxxxxxxx>
> >> > > > > > > > > > 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: <amibroker@xxxxxxxxxxxxxxx>
> >> > > > > > > > > > > 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
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
> >
> >
> > ------------------------------------
> >
> > **** 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
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|