Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Thanks to freetrader for reaching out to our support team so we could analyze the performance issues he experienced.
The workspace(s) provided had:
- At least 20 individual charts mostly intraday
- Anywhere from 150 to 400 days of day to load
- 46+ pitchforks
- And indicators on each chart including one custom on at least each chart
The problem boils down to the custom indicator which calls the DrawRegion() method for each bar on each chart which resulted in north of a million of these calls with a unique tag for each bar. DrawRegion() used in this implementation is extremely costly. A minor tweak to the indicator replacing DrawRegion() with a histogram plot removed the performance bottleneck immediately.
This might be a good test case for NT8. I am sure if the DrawRegion() is better coded in the new platform, freetrader should see better performance. Also, with the multithreading there should be some relief.
DrawRegion() is not poorly coded and in NT8, although there are performance improvements it would be immaterial in this particular scenario. Simply put, it was the wrong tool for the job. DrawRegion() is designed to color a region, not to draw vertical bars, especially 1MM+ of them, that's what PlotStyle.Bar is for.
Agreed, I don't think DrawRegion() is the proper function to use here, didn't mean to imply that it wasn't coded correctly, sorry. I agree, it shouldn't be used for this application.
What I think, not knowing all the details of NT8, is that some new technology that NT8 leverages to improve charting performance can be leveraged in a redesign of many of these 3rd party "colorful" indicators. This would require a new function that acted like DrawRegion() but leverages the video card performance for example.
My understanding is charts will be sped up with DirectX, so hopefully one of the Game Programmers in the group can help us come up with some DirectX libraries to replace some of these DrawRegion() type of visual features. That will help the 3rd party indicators play nice with NT8. I am not an expert with DirectX, but feel we can come up with a library (maybe even one that is inherited that will transparently replace the NT8 build in features with an optimized DirectX call version.
That is true, but there are ways to avoid poor coding by hiding the complexity of doing something correctly. The DirectX pipe is designed to speed 2D and 3D (2D is just the flat projection). Right now the operating system does this pixel by pixel within the CPU (Single thread), so converting the rectangle (region) into 2 triangles and handing that off to a GPU that is optimized to render trillions of triangles/second will will dramatically improve overall performance of these indicators in the future. Unfortunately, it will likely allow us to be lazy in coding again since the GPU will hide some of the inefficient coding.
I think a DirextX NT8 library would be great for performance of 3rd party tools.
I miss to set a condition like RSI 14 where the Filter Condition can be set to show value Below 30% and Above 70% so I can filter out value between 30-70%. I can't see how that possible today.