Anyone have any hints for optimizing C# code? Currently using Visual Studio for C#. Want to run some indicators through the process to see if there are any excessive computational issues.

Do you see a performance issue anywhere in your indicators?
Basically you can use .NET profiler, I don't know any freewares, but JetBrains dotTrace is very good (can use 30 days free trial), or look here:
Any Good Free .NET Profiler? - Stack Overflow

Thanks for the answer. Will be looking at the site.

Some indicators take longer to load than others, especially the recording ones, which read data from local storage, rather than my Zen-Fire feed.

ZTrade101 

Some indicators take longer to load than others.

thats very true ZT - not only the recording stuff.
i would also be interessted in the reasons of this.

last indicator i realized this heavyly was the BBand2 posted some days ago here.
i am shure this has to do wtih the plotting of the drawRegions in BBand2 and i would like to know if this eating up recources is only when loading / reloading it in the chart or also when running the chart live. and for shure also if it can be optimized some how.

so if you get deeper into this - let me know - i `d like to take part here.

thanks max

Thank you Max,

I will look into the .NET more soon, I have a friend visiting next month who is very skilled on optimizing windows applications and he has contacts who he believes can provide him with tools to see what process are using the most computational power. Seems obvious once I thought about, but it is especially important to remove duplicate efforts.

He said that the really skilled C# developers check these things at each step of building a large application. Indicators become part of NT when initiated, so there may be much more efficient was to utilize computation power.

Your investigation into mult-cpu usage, opened my eyes to one of the short comings of NT. He wondered if there was a way to get indicators to use less busy processors. That is way beyond my understanding and hope someone on the forum can enlighten me & possibly find a work around to this limitation. Or just hope NT does this for 8, the consensus on the forum is 2015.

Your friend, sadly, says a lot of bad things. MOst developers - skillfull or not - do NOT check performance on each step of development. It simply makes no sense - as most program parts normally are not relevant for performance at all. THis is a 90/10 issue - your program spends like 90% of the time in 10% of the code. No sense to optimize the other 90%

His "contacts" also should not have to provide him with the tools needed if he indeed is that skillfull. THis is like saying "I know a great cook, and his contacts will provide him with a cookbook". A good developer will know and have the tools of his trade, ready and available to him. I have Ants here, as well as the (currently preferred) VS 2010 Profilers. Do I run them often? No - hell no. I Have better things to do. Writing code. Occasionally I fire them up to see whether something sticks out - and otherwise I use them when, well, I do performance hunting Which is about once every other month. Pretty often you handle one or two items and you are over any performance bottleneck Naturally trading frameworks are a lot different than 90% of the applications out there - where the performance is simply not really dictated by the application itself. And like always, architecture is a lot more important. With all the optimization in the world the crappy NT architecture would not start using multiple cores - and that is where it would start shining.

THAT SAID - especially in something like Ninja or a similar platform, the visualization is the most likely culprit anyway. Drawing things takes time - more than calculating And on a platform / system using as primitive technology as Ninja (WinForms - I long moved to WPF, which is a lot nicer to work with) the optimization you CAN do may simply not exist - at least not on the drawing side. Ninja, as far as I can say, likes being cheap - and uses he Windows integrated user interface elements for many things. Sadly, this blows on simple items like time and sales when too many updates happen. Because it basically does a lot of redraw. On my own T&S implemntation I actually manage to offload a lot of stuff onto the GPU and avoid redrawing the text - without any written code. WPF just is SO much more powerfull

That said, carefull:

Quoting 

to see what process are using the most computational power.

Open task manager, open process list, sort by CPU usage. No other tools needed.

Here sadly the problem starts: If you talk about something like Ninja, knowing Ninja uses all the CPU is not the solution. You need to look INTO the process (in this case a .NET profiler) and locate the code block blowing CPU - which in most cases will lead you to a class that is an indicator/strategy. Process level is sadly no use here - because all indicators / strategies run within one process, the NinjaTrader process.

My only concern would be that all Ninja code is heavily crypted to make decompiling impossible (most likely to stop people from posting emabarassing bad code samples?). I am not sure how wel lthat will run together with a profiler. It SHOULD - as the resulting classes etc. still have to be legal in the .NET framework - but they may be hard to read, confusing and possibly crash something in the profiler.

That is what I was afraid of. Thank you.

I checked, he told me my interpretations of his comments were overly optimistic. He was basically telling me there was little I could do other than avoid duplicate efforts when adding indicators. Until the underlying architecture was upgraded.

NetTecture knows what he is talking about. Wise words there.

Premature optimisation is the root of all evil. Having said that, coding with performance in mind saves a lot of optimisation in the future.

It you want to squeeze every last piece of performance out of the .NET framework the 2 most important things you need to understand are:

(a) Threading (how and when to use it)
(b) Unsafe Code (again, how and when to use it)

Get yourself a box with 4 or 8 cores and offload any market data analysis work that can safely be done in parallel onto background threads for asynchronous processing. If you code it right all your cores should be sharing the work equally. For short running tasks (< 1 sec) you can make things easier by using the .NET thread pool.

Unsafe code is a whole different ball game though and you should only use it if you really need the extra performance. However, if you are iterating through large collections in your analytics code it can speed things up significantly.

Best of luck

P.S. If you looking for a good free profiler try this one from Eqatec. I've been using it for a while and it's great for a freebie.

Actually I work on something at the moment that HOPEFULLY is soon good enough to show that is among similar lines than NInja (not as powerfull, though - charting is a seconrdary tought at the moment).

Anyhow, I use ONLY the ThreadPool. Seriously. I have tons of what I call ActionQueue items - a queue that, when items are in, queues an item in the ThreadPool that then extracts them and processes them. I use a different (well, that part is still in the programming) UI approach than Ninja - I hate having tons of windows, so I use "Workspaces" that are windows that have controls on them, and a control can be a chart, T&S etc. - this allows me to basically run one window per physical screen.

Here is the trick: EVERY window gets it's own thread for message processing. That simple. 5 screens? 6 threads (one for the conrol window and some small stuff one may open separately). All connected via ActionQueues - LOTS of work (which makes it understandable Ninja never went that route) but the performance is hard. On top, I use WPF so far, and I am surprised how easy it is to beat Ninja hands down with WPF. Especially smart GPU offloading.

Example: Time and sales. Ninja uses as it loks a standard list there - which regularly redraws. BAD for performance, but extept using a more powerfull control (too cheap for that?) there is not a lot they can do. I use a standard WPF list. So far so bad - I ALSO redraw. THanks to WPF in .NET 4.0 though I can tell the control to keep the lines as bitmaps ON THE GRAPHICS CARD, so when it redraws after a scroll - only the new line is "drawn", the others come from cache. Result? Let's just say I fly compared to Ninja, with me showing every tick. STILL not working perfect - I dont have to show every tick if they come by the hundreds, so I need optimization here. But basically, WPF allows me WITHOUT a lot more programming to really really really shine