Take a look here: http://code.google.com/p/tradelink/source/browse/trunk/TradeLib/eSigTick.cs and here: http://code.google.com/p/tradelink/source/browse/trunk/TradeLib/Bar.cs Certainly it has nothing to do that with the fact it's written in C#, both you and I know that, but some readers should think a bit and do some research before they post Now that I've reviewed some codes, I clearly think that the performance issues is caused by the design and the way Tick/ Bars is handled. No wonder that it couldn't handle 20 symbols!
Strange that you would say that, considering no one has seen the source for tickzoom. Have you seen the source to compare it with anything ? How can you say 'do research' against what is basically a closed source project? What 'research' have you done ? Until greaterreturn actually posts some code, I think YOU should hold off doing any more 'research'.
Is the .tck file it is reading from a flat file or a database file ? I presume most users would want their data collected into some kind of database to make ongoing data updates easier and simulation runs involving subsets of the data more efficient.
Wayne - Very impressive so far. I had some issues with the mp4 format though. Although i resolved the, quickly, others may not be able to. You may be able to upload the video to YouTube & link to it from there. I think Camtasia or Cam Studio can export videos in that format. Eric
Agreed. I saw that too. Plus it has a ease of use issue in the Bar.cs but treating each "Bar" as a class and having an array of "bars" with high, med, low, close. It should be designed as a single Bars class with array of High, Med, Low, Close (like T.Z.) so you can interchangeably use functions like Highest(High, 5) or Highest(Close,5), etc. Good catch, Janus. Wayne
Graham, thanks for asking. I know how you feel. I assumed the same thing originally and, as a database speed guru, I thought something would work. Problem is that when reading 10Million ticks, if the database takes more then 1 microsecond to read each tick, then it will take foreever to load them. At 10 microseconds, it takes 100 seconds or almost 2 minutes to load the file. I found that even the fastest possible with OODBMS was about 30 to 50 microseconds. Now, that's extremely fast compared to RDBMS but it's not fast enough for my taste at reading ticks. Problem with those is they have overhead since they know how to do alot more than handle ticks. I haven't completely give up on OODBMS. Especially if we use one that's open source. Question is, will it be easier to just change on OODBMS to turn off all the functionality we don't need or just make our own data organization. Noone has come up with any other query we need to do other than Symbol and time range. So if we simply make a separate folder for each Symbol. And drop tick files in there which each have a "header" with the offset to every 10,000 tick boundary, that will be very fast and easy to work with since you just drop files there whether they cover 1 year, 6 months, 3 months, etc. That's my thought at present and I'm open to well tested ideas in that area. Sincerely, Wayne
By the way, you're right, when we do what I described, we want to have the software interface just allow a drop down for symbols. Then the software finds the correct date range. Wayne