NinjaScript Code Size Limit ?

[KonstantinosNT]

As the number of an Automated Strategy Sets in the Strategy Builder is increasing, the produced NinjaScript code lines and its size (in Kb) are increasing correspondingly.
My questions are:

1) Is there a limit regarding the number of Sets that Strategy Builder can support ? (As the number of Sets increase, the automatically produced NinjaScipt code is increasing also).

2) Is there a limit regarding the code lines or its size in Kb (or Mb) of a NinjaScript code in general ? Can NinjaTrader support and execute a NinjaScipt code of any (large) size ?

[NinjaTrader_Jesse]

Hello KonstantinosNT,

There are not any documented number of set limits for the builder so I am not certain if there is an upper limit there.

NinjaScript is being compiled by the C# compiler so the only limitations would be any that the C# framework has. There is no upper limit on the number of files compiled that I am aware of however the more files there are to compile that will increase the compile time. If you have a very large number of C# code files and also imported third party assemblies it can take up to 30 seconds in some cases to complete a compile. If you see there is a lag when compiling it would be suggested to reduce the number of items being compiled by removing some items you don't use.

[jeronymite]

My own code as a "random" example: AddOn files (43), Indicators (11), Strategies (3), total 128,034 lines, 5MB. Compiles in "a couple of seconds".

The only variant that seems to affect the compilation time is the number of NinjaScript Editor windows open. More than 3-4 separate editor windows makes the compilation "pause" for several seconds. If more than 10, it can add 10-20 seconds to the time. Close those windows, and compilation goes back to "don't blink or you'll miss it".

Again, the NinjaScript Editor is problematic in this respect. The number of editor windows used to have no effect in NT 8.0.25.x and earlier. From NT 8.0.26.0, the delays corresponding to increasing numbers of editor windows started. Still there in NT 8.1.x.x. Sigh.

[I use a separate editor window for every file, not separate tabs. The reason is because of the enormous number of bugs in the current NinjaScript Editor from Actipro Software. (SIGH!) I could use Visual Studio, but I do not choose to do that for various reasons.]

Thanks.

[KonstantinosNT]

Hi jeronymite

Thanks for your info.
In what hardware your example does compile so fast ?
My far smaller Strategy compiles much slower than that.

[jeronymite]

KonstantinosNT Intel Core i7-3920XM, 32GB memory, SSD System disk, Win10 Pro.

Thanks.

[QuantKey_Bruce]

I could use Visual Studio, but I do not choose to do that for various reasons.

Any you would care to elaborate on?

[jeronymite]

Thanks for asking, QuantKey_Bruce

I started developing NinjaScript in 2011, using the NinjaScript Editor, which for many years was the only half-way decent and readily available and convenient editor for NinjaScript.

Whilst I have VS Pro 2019, I have no great need to use many of the grand VS features to do what I do in NinjaScript, mainly because of an established approach developed, adapted and refined over more than four decades that serves my purposes well. That includes designing, debugging, syntax checking, code validation, formatting, etc. It's a not a matter of the sophistication of the code I'm writing (I tend to push the envelope), but more simply just the way the tool works.

There are some functions in VS I like to take advantage of that help minimise code bloat. And the Designer can be useful, but with insight derived from many years of playing with XAML, a few quick edits of existing designs, or "variations on a theme", are just as easily rendered into good UI functionality. Otherwise, the simplicity of the Actipro Editor is useful in some ways, albeit somewhat counter-intuitive to the concept that a "bigger, better" tool must be better.

Importantly, using the Actipro Editor "forces" me to avoid constructs and functionality that are not supported by the long-obsolete versions of the underlying technology in the current version of NinjaTrader ... sadly.

I have chosen to use VS for particular things where it offers clear benefits over my current practice, and to otherwise focus on the development itself, rather than the tool. I put up with the manifest inadequacies of the currently integrated version of the Actipro Editor mainly for those reasons.

Thanks.

[bltdavid]

I'm in the same boat as jeronymite.

I have had Visual Studio 2010 Enterprise and only ever used it for NinjaScript
when I needed to use the profiler to find out why some code was so slow when
backtesting. I'm used to gdb, but now, for most of my purposes using C# and
NinjaScript, I find Visual Studio is very heavy-weight.

I use gvim for all my editing. I only use the NinjaScript editor to compile, or
to make simple fixes found during compilation.

-=o=-

Alternatively, I wrote a Debug library that automatically opens the output file
on the first call to Debug ... lots of great features. It can print msgs to the
output window, or an output file, or both -- all msgs are time-stamped, too.

Using an abstract base class, all my indicators and strategies automatically
get access to this Debug method. Works great.

In addition, to the quick compile times (which means I can add some extra
Debug lines, recompile, and be back in a test mode pretty darn quick), the
simple concept of using Debug (and/or Prints) to output things of interest
has been a pleasant experience with NinjaTrader.

-=o=-

I also use a 'tail' program to watch my debug log file as it's being written to.
Learned this trick long time ago -- have you ever used 'tail -f logfile' on Linux?

Since I'm a Unix/Linux guy at heart, I love being able to use 'tail -f' again in a
Windows environment with BareTail -- it has helped to make debugging via
my debug log files simple and fast.

Btw, BareTail is free, has no installer, and works in all versions of Windows.
I'm using it now in Win7/10/11. I copy it to C:\Windows on all my machines.
I really love the color highlighting. Even bought the BareTailPro version,
but the free version is quite sufficient, I actually use it the most.

(Yeah, I know, I'm done for, C:\Windows is a sacred place... oh well :-)

Just my 2˘.

[KonstantinosNT]

I have created some strategies via the Strategy Builder tool. One of them has ~600 lines of code (automatically produced from Strategy Builder) and also some added 32.000 lines under the segment:

#region Wizard settings, neither change nor remove

Is there a possibility that my long times to compile are due to those ~32.000 lines which are following after the main code ?

[bltdavid]

My guess: probably, most likely, maybe.

Have you devised some testcases whereby you
compile with the long form of your strategy, then
exit/restart NT and compile with the short form?

I presume compiling the abbreviated shortened file
(with those lines removed) will be faster.

How much faster, I dunno.

Measure your test runs as carefully as you can.

[QuantKey_Bruce]

Since I'm a Unix/Linux guy at heart, I love being able to use 'tail -f' again in a
Windows environment with BareTail -- it has helped to make debugging via
my debug log files simple and fast.

I have a lot in common with you fellows, and cut my teeth on BSD and later SCO Unix. I use various Linux distros every day - for server-side operations. Sometimes in a Zoom when I'm discussing/working with younger developers and they see me fly around in vi or emacs looking at server-side issues without touching the mouse it tends to elicit comments you might get yourself, like, "What sorcery is this?". But, I use Visual Studio when developing for Windows because of the integrating debugging, integrated Git, and many other things that I would be slowed down to do without.