Faster when Esignal Window is closed

[esquid_12]

I have a C++ application that calls RequestHistory and dumps the results into Excel.

I've noticed that the time it takes to request and receive the history from the Esignal API depends on if the ESignal main application window is still running. The difference is up to 10x faster when the ESignal App window is closed. It is especially pronounced when getting tick data (ie. lots of data).

---
Here is how I see the difference:
1. Start up my C++ program
2. Link to Esignal
3. Run the RequestHistory - Speed ok

4. I exit the main winsig App window
5. Winros data manager and winsig.exe are still running, just the winsig window is closed
6. Run a different RequestHistory - Speed is now 10x faster
---

Why is it so much faster when I close the Esignal window? Just minimizing it doesn't make it faster. Turning everything off in the Esignal window ( ie. a blank page), doesn't help either.

I have plenty of RAM and it's not a CPU thing. It just seems that the requested data is held-up by, or is being used by, the Esignal Main Window.

Am I missing something? What is the Esignal Application window doing that slows down the data transfer? Is there a setting that I might need to change somewhere?

I'd like to be able to get the faster speed and still have the Window running. Anyone else seen this?

[GenSpoo]

Interesting. I assumed closing the main eSignal app would kill the API connection. Seems to have not, although winsig.exe is the main app and it is still showing in the process list. So I assume it is the fact that we have a COM connection open to the app that must be what is keeping the process alive.

Is the call still 10x faster if you didn't make the same call while the app was open? The Data Manager caches the data so if you do the exact sequence of steps you provided below, that could account for the increase in speed (as opposed to just closing the app window). It could also be a little faster since it wouldn't have to spend process time drawing its own windows, etc.

Cheers... George

[Guest]

This is interesting. The Desktop API is a COM interface to the eSignal application. Winsig.exe should not remain as a running thread if you close eSignal, but I guess this is a positive side effect (kind of like penicillin).

If you are just interested in real-time tick data, why not just use DDE?

[esquid_12]

It's faster either way; requesting a different symbol or the same one again. It's mainly noticable when doing many requests at once. I'm not really complaining since more speed is always better. Just wondering if it's possible to always have it.

I think I narrowed it down a bit. It seems that most of the speed difference is from accessing the data once it has been downloaded. Without the Window running, it can be almost instant. With the window running, it's several times longer. For example, I have a 1 day "1t" RequestHistory for "AA". With the window open: First time to download and read is about 10 seconds. Requesting the same thing again and reading (I wouldn't usually be doing this, but I'm just narrowing down what's happening) takes about 8 seconds. Do the same request again: 8 seconds. If I close the window, and request the same thing again for a fourth time, it takes about 1.5 seconds, fifth time 1.5 sec, and so on. Of coarse, requesting a new history with the window closed will take longer than 1.5 sec.

I doesn't seem that the window redrawing should do anything. I usually have a blank page with the window minimized when testing the API. I'm wondering maybe if there is something (a timer maybe) in the winsig message loop that's interrupting things when the window is open. Or, maybe the COM calls to GetGetBar are blocked temporarily (ie. a temp BusyState).

Originally posted by GenSpoo
Is the call still 10x faster if you didn't make the same call while the app was open? The Data Manager caches the data so if you do the exact sequence of steps you provided below, that could account for the increase in speed (as opposed to just closing the app window). It could also be a little faster since it wouldn't have to spend process time drawing its own windows, etc.

Cheers... George [/B]

[JimBecker17]

My work is slightly different, where I always keep winsig visible as well as the COM connection. But have seen the slowdown and figured out how to minimize it for my needs.

When getting Tick Data way back when really noticed this and did report it. It seems to be based on the number of windows that are open in eSignal, so the more open the more response time degrades.

The Tick Data comes across a single tick at a time, so there is that much more effort eSignal seems to make in some form of "round robin" mode of checking for window updates or something.

The hunch is it does a COM operation, then proceeds to check all open windows before doing another.

My app that gets the Tick Data opens an "empty" layout file before it gets the data, which closes all open windows (assuming i'm around to click off all the "do you want to save" prompts i get from eSignal on the existing layout file). Sounds like just not having a visible winsig is the best approach though.

On a somewhat different but related subject:

If the long requested array mode for tick data was ever done, someone please let me know. I've been working in other areas and am not current with any changes.

-Jim