|
PureBytes Links
Trading Reference Links
|
Ouch! What a killjoy. :)
That's fair enough from your point of view Tomasz, but this is a user forum, and the mulling over of ideas whether ignorant, uneducated or completely missing the point is all fair game.
I'm well aware of the limited (probably zero) impact of these forum posts in relation to your actual development of AB, but posting them gets a lot of ideas out and solves a lot of problems in itself. I've answered heaps of my own questions, just by writing posts, many of which I never need to end up sending, and which in hindsight were foolish. Of course there's always some that get through the filter. :)
There are innumerable posts on this forum from beginners and non programmers that I think are stupid, but I don't bother writing to let them know!
So my advice is to stick to development and leave the forum nonsense to us. :)
Tongue in cheek,
Jules.
--- 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/
|