Performance Issues

[Gavishti]

Does anyone have some definitive information on the following performance issues?

1. Is getValue() or close() more efficient?

From what I have seen in Performance Monitor it appears that close(), open(), etc. is more efficient. I had figured these to be wrappers. It looks like they are not.

2. At what point is it more efficient to use var nClose = close() as opposed to just using close()?

At some point it should more efficient to store the variable than to keep making the call.

Thanks.

[dloomis]

Re: Reply to post 'Performance Issues'

I am not sure, but if you are worried about the overhead of close() vs
getValue() on cpu performance, you need a bigger cpu.

[gspiker]

I believe you will find that the resolution of the timer in the performance monitor and the latency of system calls and context switches will have more effect on the results of your tests than on which of function (close() or getValue()) you use.

Garth

[Gavishti]

JavaScript is an interpreted language and by its nature is slower than a compiled language. It seems that regardless of the language used it is best to use the most efficient code whenever possible. There are users with new dual processor machines that are getting bogged down. If throwing more hardware at the problem is the solution then the following seems pointless:

setComputeOnClose() - often cited as a way to make an EFS run faster.

if (getBarState() == BARSTATE_ALLBARS) return null; - another segment of code cited as a way to get the EFS to run a little faster.

If efficient code is not important it would be much easier to put all of the functions that are used repeatedly in separate EFS files and use callFunction() as you would do in a compiled language.

If getValue() takes twice as long as close() why would you want to use getValue()?

If retrieving a variable from within your EFS is twice as fast as using a function to retrieve the data why would you want to use the function any more than necessary.

In most, if not all, interpreted languages even the length of the variable names can affect the performance. It is usually worth the small hit on performance for readability. Same with the use of functions within the program file as opposed to embedding everything in main().

Being new to JavaScript I don't know the answers to these questions. I am just assuming that there is a difference since this difference exits in other languages.

[gspiker]

Gavishti,

Well, Since you are not sharing with us your methodologies for testing this, nor your actual number results my reply had to be based on assumptions. They could be wrong.

Assumption #1. Since the EFS performance monitor doesn't measure the cost of specific function calls, I assumed you tested this by creating two functions (one with getValue("close") and one with close()) and that these are the only function calls in the formula:

function main()
{
close();
}

For example.

If so then you would have to run this a number of times (at least 5-6) and take the mean of the result for this number to have any meaning. It's not clear to me that this is what you have done.

If this isn't the case, if there are other function calls, if the EFS are not simple and exactly the same, then no conclusions can be drawn from any tests that might have been run.

Assumption #2. That the results of such a test resulted in a VERY small total time. Please understand that the resolution of the timer is not great, and not accurate to a high degree. The idea was to identify efs's that were chewing up a large amount of CPU time, not to be used similarly to a compiled language performance analyzer...which can often give you highly accurate results. I wish I could remember the resolution of the timer...I think is wasn't even 1ms, but could be wrong. It rounded results to the nearest whole. This means that a test that results in a 1ms time and an other that results in a 2ms time may not 1ms different. And even results that very by a 5-6 ms are not meaningful.

Assumption #3. That the system was not quiescent, other than the eSignal app. Once again this would force the need for running the test multiple times. A single context switch when running the test would result in greatly skewed numbers. Yes, this means (if I remember correctly, and I'm pretty sure I do) that this is wall clock time and not actual code running time that is reported.

Maybe some information on your end about methodology and results would help...

SetComputeOnClose() and checking for NEWBAR are methods that will work in helping to reduce dramatic CPU sucking EFS from dramatically sucking your CPU. This is even more true on tick charts and charts with highly active issues being displayed. In reality even on ES #F tick charts I haven't had any need to resort to either of these in any recent release...and I run some very complex and intensive EFS scripts.

If getValue() takes twice as long as close() why would you want to use getValue()?

Well, depending on the numbers I wouldn't. In general most people don't use getValue() anyway...it takes longer to type ;-). The only case where I use it is if I leave the source of the data up to the user...getValue(nSource);

But again, I would have to see some very compelling numbers, and really understand how they were attained, to make me go one way or the other.

If retrieving a variable from within your EFS is twice as fast as using a function to retrieve the data why would you want to use the function any more than necessary.

Clarity. Ease of modification and support. The typical reasons. So far even with very modular code I haven't see any performance hits.

There are users with new dual processor machines that are getting bogged down.

eSignal is not threaded. Unless you hope to offload other major tasks running on your computer to the second processor, going with a dual isn't going to be a big helpful. For eSignal high GHz is more important that dual CPU.

Garth

[Gavishti]

I am not claiming one function is faster than the other. I am asking if anyone knows which is faster. I did run multiple tests using several thousand iterations and comparing times. Based upon those very simple tests, statements from eSignal (like don't use getValue("time") because it puts an extra load on the CPU), and a little deduction I came to the conclusion that close() is probably not a wrapper of getValue("Close") but a separately coded function. These things imply, but do not prove, that close() is slightly faster.

Just from a quick look at Performance Monitor it doesn't look like a very precise tool. I never figured that the statistics coming back were highly accurate. Just something to get in the ballpark. Better than not having a tool.

It is interesting to know that eSignal is not multi-threaded. That kind of programming can be difficult. Perhaps that is why. I never thought that JavaScript was multi-threaded. There are users ought there complaining about performance. Many have machines considerably above the recommended 800MHz P2 with 256MB RAM. Many have machines with faster CPUs than mine.

Personally, I am not having problems with performance on my EFSs. When I write code I prefer to use the faster way over the slower way as long as it does not interfere with readability or ease of modification. I have worked with a few programmers that always had faster running code than everyone else. The things I have mentioned are among the ways they did it.

I am simply trying to find out, in a language I am unfamiliar with, which is the faster way. I know I can throw hardware at it or get a compiler and write DLLs to improve performance. I want to improve the performance of the JavaScript that is provided. It is much simpler and cheaper than the alternatives.

Given a choice between a profitable system that is inefficiently coded and an unprofitable one that is extremely efficient I will take the inefficient one every time. I am no longer in the software business I am in the trading business.

[gspiker]

Ahhh ok, sorry to be slow on the uptake on this.

My understanding, based on the phrasing of the very early EFS documents, is that close(), open(), etc are just wrappers for getValue(). I have never seen the code, but the author of the doc's was the person who wrote the code. So I suspect this is correct. Given that the wrapper would be written in C or C++ and embedded in the eSignal EFS engine, I would be surprised if there were any noticeable difference in times.

The reason getValue("time") is specifically called out, is because it uses the JavaScript date object, which is very heavy in nature. Too many of these will swamp even a high end CPU. This is one of the rare calls to be able to do this, and eSignal has created a work around (rawtime) that will work for ALMOST all cases where getValue("time") would work.

I try to store the results from function calls to the EFS Engine in memory for efficiency, but I have seen many EFS's that will do multiple calls to the same function throughout one iteration of main(). They still seems to run fine, without killing the CPU. I'm not sure what would happen if you load a dozen such EFSs into a dozen or so charts...it may indeed start to cause problems.

I don't worry as much about function calls internal to the EFS itself. There seems to be very little overhead in doing that. This I really did test and the results showed no measurable (with the EFS performance monitor) differences.

Hope that helps...

Garth

[fabrizio]

Garth

I must confirm that what counts in EFS Esig is the speed of the processor, but a reliable speed with a reliable MB. No sensible improvements over 1 gig of ram

I have no major problems here with the bulk of studies I have loaded on the different pages and charts. Indeed it all depends on HOW the EFS is written : to drawn down or not your cpu power.

However the simple but very limited macro like language of CQG
brought extensive or Genetic Backtesting with a double P4 3.0 from 1 week to 1.7 days.
Same with Bio Comp neural software where isa a must.

Eventually I abandoned both ( even if I miss just couple of things that are in the pipeline of Esig.)

Another world (close) to a new world ( open) which will be even more open with the "blocks" of functions approach in writing EFS