karlwancl / Trady

Trady is a handy library for computing technical indicators, and it targets to be an automated trading system that provides stock data feeding, indicator computing, strategy building and automatic trading. It is built based on .NET Standard 2.0.
https://lppkarl.github.io/Trady
Apache License 2.0
545 stars 185 forks source link

Upgrade compiler to 7.3 #65

Open irperez opened 6 years ago

irperez commented 6 years ago

The latest compiler version 7.3 allows us to take advantage of some good performance features that were not available.

In particular the use of ref, in, out keywords in ways not possible before.

This may be useful especially when dealing with a large amount of candles. Using references instead of objects as it may boost performance.

So for example, the original did without the "in" keyword:

public class ExponentialMovingAverage : ExponentialMovingAverage<IOhlcv, AnalyzableTick<decimal?>>
    {
        public ExponentialMovingAverage(in IEnumerable<IOhlcv> inputs, int periodCount)
            : base(inputs, i => i.Close, periodCount)
        {
        }
    }

The "in" keyword ensures that the function uses a reference to the actual IEnumerable object, but cannot modify the reference. The original code actually makes a copy of that IEnumerable.

https://dotnetcoretutorials.com/2018/01/08/new-keyword-c-7-2/

irperez commented 6 years ago

Just realized that variables that have the "in" keyword assigned are not allowed to be used by LINQ queries...

karlwancl commented 6 years ago

Could you elaborate more, or is there any reference on that? Because i have just moved the compiler version to "latest" (latest is 7.3 I suppose), and have tested marking an "in" keyword for inputs in AnalyzableBase class, and the test case runs properly without any issue.

irperez commented 6 years ago

If that's the case than it works in some situations and may not work for in others. We may have to learn the rules around "in". Compiler complained when put "in" with a function that used that parameter within a LINQ statement.

We just need to be sure that any use of "in", there really is no modification of that objection. It's just for reading. And we need to be very careful of using "in" on structs as that can slow things down.

karlwancl commented 6 years ago

yea, i agree. We must make sure the suitable use cases of "in" parameter first before we proceed the change. And for the case you've mentioned, could you branch an un-workable version for me to investigate the problem, i mean the "not allowed to be used by LINQ" use case.

alikalfaoglu commented 4 years ago

Suitable for value types only. Objects are already passed as byref.