Assuming it is, in fact, a coding issue, and without knowing anything about the code, then I guess one possibility is:
The first thing that comes to my mind is that the code is populating Excel one cell at a time, rather than all at once. The overhead could possibly be multiplied by the number of individual cells being written to, in this case.
The interaction between Excel, SQL, and C#, is not my thing; but if these guesses/assumptions are correct, then it certainly may be a coding issue. (Probably easier [and less expensive] in this case, to code one cell at a time vs coding an all at once transfer)
I'm curious to know what the original coders say about it.
Again, this is not my area, but using Excel probably greatly sped up development. But it may actually be fast enough if the above bottleneck (assuming it applies) is addressed. Just my guess.
Another option is to have C# do whatever you're doing with the excel data while trading. Have C# output the conclusions you would have drawn via the Excel sheet ... GO or NO-GO ... BUY, HOLD, or SELL ... ETC.
The app could still give you your original excel output if and when desired (after the trading session, for example) for your research purposes.
The first thing that comes to my mind is that the code is populating Excel one cell at a time, rather than all at once. The overhead could possibly be multiplied by the number of individual cells being written to, in this case.
The interaction between Excel, SQL, and C#, is not my thing; but if these guesses/assumptions are correct, then it certainly may be a coding issue. (Probably easier [and less expensive] in this case, to code one cell at a time vs coding an all at once transfer)
I'm curious to know what the original coders say about it.
Again, this is not my area, but using Excel probably greatly sped up development. But it may actually be fast enough if the above bottleneck (assuming it applies) is addressed. Just my guess.
Another option is to have C# do whatever you're doing with the excel data while trading. Have C# output the conclusions you would have drawn via the Excel sheet ... GO or NO-GO ... BUY, HOLD, or SELL ... ETC.
The app could still give you your original excel output if and when desired (after the trading session, for example) for your research purposes.
That's what I suspect. Thank you for confirming. Having been a 'nice' customer up until now, I made a complaint about this on Friday. Let's see what they answer...
Correct.
Basically, I have an application in C# which calculates various intraday statistics outside of Excel and store this in a SQL database. This happens fairly fast. And frankly, most of the statistics are fairly flat forward and basic arithmetic. Some if/when formulas for sure, but nothing staggering.
But, loading the data in Excel takes 10+ seconds for the 'easiest' data set and yesterday I measured 90 seconds for a set that's more 'complex', although it shouldn't really be much difference IMO as far as logic is concerned.
As far as I know, there are little to no calculations done inside of Excel. It's basically just used as a GUI as you say. There are some macros/VBA to view and sort the data...
Loading the data set is slow and loading new days (if I want to check individual days in detail) is slow...
Basically working with 5 years of data now and would love to extend it to 10 years at least, but doesn't seem viable with the current solution.
Without further detail - does the use of Excel as a GUI seems like a reasonable solution for this? Or might the limitations be with Excel?
I do like Excel as it's easy for me to manipulate data there and do some basic calculations of my own. Export data to new sheets, etc.

