Date Object

[pflash50]

It seems that if I want to display the "Time of Last Tick" to the second, I must use a Date() object. The short cut getSeconds() is still not working.

(This allows me to use seconds data from the system clock, and most of the time a new bar starts within one second of the system clock rolling to the next minute, so it works well enough to be useful.)

===

In your Help article about the Date() object you warn that it is a resource hog.

So when I first tried this I created the Date object with the other global variables (outside of any function) hoping to avoid creating more than one object. It worked just fine.

Then, as I added more stuff to my program, I reached a point where the seconds part of the display froze (at 44, if it matters). Hours and minutes (using the short cut functions) continued to update as expected.

After tinkering with is for a while, I found that if I moved the object creation code into main, the seconds part of my display began to function again.

Q1) Can anyone explain this change of behavior?

===

I'm beginning to see some sluggishness in the initial load of my program now. Once into real time operation, however, it seems to be able to keep up.

I've added lots of other stuff besides the date object, so some of the sluggishness could have other causes.

This is the code I'm using now for getting my "Time of Last Tick" data , and it runs on each new tick.

   var today = new Date();
   //
   var Hr   = getHour(0);
   var Min = getMinute(0);
   var Sec = today.getSeconds();

Q2) Any suggestions about a better way to do this?
Q3) Am I creating an additional object on each tick?

===

Q4) Is there a way to tell how many objects a program is actually creating?

Q5) Is there a way to destroy objects that are no longer needed?

pflash50,

here is a link where I investigated how much time calling the date object took.

http://forum.esignalcentral.com/show...+000#post30983

While comparitively it takes more time that calling bar time, when you look to see how many times I called it and the time it took, I do not believe it is significant... tried to find the efs I wrote to perform the test, but could not. I hope this is helpful.

btw, some of your questions are also addressed in my other response to another post

http://forum.esignalcentral.com/show...&threadid=9512

Regarding sluggishness and declaration of variables and where you declare them, I also use functions almost exclusively. I recently had an issue similar to yours where I had an efs that was unexplainably sluggish. I finally found that it was related to a "while loop" I had that I was exiting from, legally I believe, however, it was quite madening.

After about a week of troubleshooting, I made that section of the code simpler, eliminating the "while loop" and the execution time for the efs went from 2 miliseconds to .015 miliseconds.

Other things that can make efs's sluggish are excessive file open and writing to the file, file reads, etc. I have also had problems with my trace utility since it opens and writes to file a ton. I have found this to be of limitied usefulness when trying to troubleshoot problems with execution speed.

Generally, what I do is start going around the code and commenting out sections of the code while I am running the code in playback mode using the Performance Monitoring tool as a measure of how each section of code that I am commenting out has an affect on execution speed. (you have to reset perfomance monitor each time which is not a big deal.

Now, this has not answered your questions directly, however, I am hoping this will help.

good luck

[gspiker]

doing output to the formula output window can also cause sluggishness.

watch out for putting debugPrint() and debugPrintln() in loops...that can really hurt performance.

G

Yes, good catch Garth! It is kind of a sleeper. Using debugPrint or debugPrintln has an immediate impact on execution speed. It also has a cummulative affect that is not apparent. The larger the formula output window buffer is, the longer each write takes. The way I get around the cummulative affect is that I clear the buffer every hour as follows:

if (CurrentHour != getHour(0)){
  CurrentHour = getHour(0);
  debugClear();
} 

where CurrentHour is a global variable.

While this flushes the buffer, you really do not lose any information output using debugPrintln since it is accessable in the eSignal directory. The file name is formulaoutput.log and this is the cummulative output to the formula output window which is only reset (erased) upon eSignal re-start.

[pflash50]

I put my output window on a strict diet almost two years ago when I discovered the impact it has on performance But I didn't know about the log file, and that is very useful. Thanks.

===

In this case my sluggishness was caused by ... what is probably a design weakness in eSignal. But I'm not positive. It could still be something I'm doing wrong.

There are several errors you can make in your code that OUGHT to cause the compiler to complain, but don't. At least, they don't always cause it to complain.

EXAMPLE: using "=" instead of "==" when testing for logical equality. In a small simple script the compiler usually catches this and gives you a big red message, complete with offending line number, in the output window.

But in larger more complex scripts there is never an output window message for this error. You get a flag next to the script name on the chart that says "formula error", but that is it. Sometimes, if the error is deep enough in the code, parts of your indicator will be displayed before the script fails. Sometimes it takes a long *long* time for the script to fail.

After a while you learn to go look at the last logic test you did for the source of this problem.

===

The sluggishness this time around was caused by changing a scalar variable to an array. I thought I had found all of the previous references to the scalar notation. But there was one I missed and I was setting the aray to zero instead of setting one of it's elements to zero. Since the reset was conditional, the problem didn't show up right away.

No compile-time error message (because you can legally assign a new value to array's address) but it took a really long time for the system to actually decide it couldn't figure out what to do. And of course the run-time error message complained about something else (no properties in a parent object).

Suggestion - If there were something like an "address" operator in eSignal for changing the address of an array or object, then the compiler would be able to warn when you forgot to include a subscript in an array reference.

But, knowing that I was not up against any limits imposed by the use of objects was a big help.

Thank you.

I can empathize with your plight having been there multiple times. I have been writing all my code lately such that it can be run in $playback or real time. This took a while since the current time returned from the date object really is not comparable with the timeframe you are testing, however I was able to get around that, in the way I tested using a check to see if the efs was in playback mode. I was not however trying to determine tick time, merely bar time.

best wishes,