I know there are some limitations to Powerlanguage Editor functionality when one exceeds a certain amount of chars in the code.
First the Editor stops coloring the code and then there is a lines maximum that you simply can not exceed.
I am in the first situation where the Editor has stopped coloring the code. This makes coding a lot harder. Is there an option to turn off such a behavior? I mean, I understand that this is in place for performance issues but I would rather have low editor performance than no colors. When you have big chunks of code, colors result in faster handling and less mistakes.
Second, is there an option to "include" a part of the code written in another file by using an appropriate statement? Like say in PHP include("somecode.ext") or something? This would be really helpful for studies with large codes.
Powerlanguage Editor - Max Colored Chars
- TJ
- Posts: 7752
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2228 times
original quote by Marina Pashkova:
I also had some indicators that exceeded 1,000 lines.
Actions I have taken:
1. reduce the number of lines by tightening the code,
2. do not start a new line whenever possible (not a good coding practice, but...)
3. move sections of codes to a function.
HTH
Hi guys,
Studies in PowerLanguage can contain up to 10,000 lines.
However, after 1,000 lines the code is not coloured - to enhance performance.
I also had some indicators that exceeded 1,000 lines.
Actions I have taken:
1. reduce the number of lines by tightening the code,
2. do not start a new line whenever possible (not a good coding practice, but...)
3. move sections of codes to a function.
HTH
Thank you for your reply TJ.
It is not only a matter of lines. It is also a matter of number of characters (just fyi).
I am using the "tricks" you describe. Otherwise my full code would go above the maximum of 10,000 lines.
Even using all the tricks I am still over 5000 line in the main body of my code.
Anyway, I could segment the code further into more functions but sadly that would hurt calculation performance. At least this is what I think it will do since it will double-calculate a lot of stuff.
And if I do it in a manner that avoids double-calculations, then my code will get very hard to edit.
Oh well, I guess I will have to live with no colors in my code. I do insist though that there should be an option to turn of and on colors on choice and not automatically. As I said above, it should be up to me (the coder) to decide if prefer editor performance over usability.
It is not only a matter of lines. It is also a matter of number of characters (just fyi).
I am using the "tricks" you describe. Otherwise my full code would go above the maximum of 10,000 lines.
Even using all the tricks I am still over 5000 line in the main body of my code.
Anyway, I could segment the code further into more functions but sadly that would hurt calculation performance. At least this is what I think it will do since it will double-calculate a lot of stuff.
And if I do it in a manner that avoids double-calculations, then my code will get very hard to edit.
Oh well, I guess I will have to live with no colors in my code. I do insist though that there should be an option to turn of and on colors on choice and not automatically. As I said above, it should be up to me (the coder) to decide if prefer editor performance over usability.
- TJ
- Posts: 7752
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2228 times
if multicharts stores internally the results of the functions and does not re-calculate over and over each time you call them then yes, I agree.
But is this the case when it comes to custom functions with random inputs?
Again, I don't know how multicharts is coded but it could be possible. It could also not be. In the case that it does not, functions called twice would result in more calculations.
In general you are right of course. When it comes to my code, things are not so simple anyway so, this is out of topic actually.
But is this the case when it comes to custom functions with random inputs?
Again, I don't know how multicharts is coded but it could be possible. It could also not be. In the case that it does not, functions called twice would result in more calculations.
In general you are right of course. When it comes to my code, things are not so simple anyway so, this is out of topic actually.
- TJ
- Posts: 7752
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2228 times
my CPU seldom risen above 20% (Q6600),
I don't know if "speed" should be a concern with today's computer.
but then, not many people have 10k line indicators (I don't), so I can't make a judgement on it.
I have read a very complicated strategy,
it has a study-to-function ratio in excessive of 1:100
i.e. for each line of code in the study, there are 100+ lines of code buried in functions. It was quite an eye-opener to see the architecture.
I don't know if "speed" should be a concern with today's computer.
but then, not many people have 10k line indicators (I don't), so I can't make a judgement on it.
I have read a very complicated strategy,
it has a study-to-function ratio in excessive of 1:100
i.e. for each line of code in the study, there are 100+ lines of code buried in functions. It was quite an eye-opener to see the architecture.
I have a Q6600 too. Like yours it never rises above 20% when the strategy is calculated in one chart, simply because multicharts assigns each chart to a single core. Thus the most you will get from one chart is 25% weather you like it or not (and I dont like it).
The performance issue is no issue at all in real time. The issue rises when in research and backtesting.
The performance issue is no issue at all in real time. The issue rises when in research and backtesting.
- TJ
- Posts: 7752
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2228 times
- TJ
- Posts: 7752
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2228 times
Interesting topic, maybe some TSSupport members can answer the question if
functions are faster/less cpu intensive.
As i remember it correctly on the TS Forum the advice for strategys was given to code all inline, because functions and especially functions in functions are calculated slower.
you don't need anybody to tell you the answer...
because no matter what answer is given,
the question will be asked again.
all you need is to make 2 indicators,
one with inline code,
another with the same code in a function,
make both reiterated XXXX times,
then
add this code before and after the calculations:
print(text(currenttime_s));
and you will see the time stamp in the PLE output log.
I am not disputing TS's suggestion,
because inline vs function is not an apples vs oranges question;
different mission requires different solution.
Doing something for the sake of doing it will always yield disappointing results.
p.s. if the time stamp does not give you a satisfactory answer, read my previous posts for answer.