Tickstory

I let my membership lag a few months and then paid the yearly to get going again. Since then, my file exports are insanely slow and appear to be using only one core. If I tell it to use 10 operations at once in settings, this brings the program to its knees. It cannot even refresh its display. Prior to this I could set it to use 28 cores (out of my 32) and it ran like a champ with no interface lag. My whole machine was completely available to me and Tickstory could export 28 files no problem.

So what is going on now? Why is it that 10 files are killing the program? Why does it show up as Tickstory Lite in the Task Manager?

Thanks

Hi Tradebuilder,

We're not aware of any recent software-related changes that would cause this issue. It could be that the load on the data servers is currently high. This can occur especially during the weekends where maintenance is sometimes conducted. In the first instance, you might want to try reducing the number of simultaneous downloads to see if this alleviates the problem. If too many data connections are made during peak periods, the servers may throttle data requests to ensure it is accessible equally to all users.

Hope this helps.

Sorry, that does not help. I am talking about file exports.The entire Tickstory.exe screen is black with only 10 exports running on data that has already been downloaded. So it should not be hitting the server. Is it possible that my Tickstory program is actually running as Lite or in some way not multi-thread aware?

Okay, I saw a post where you day that he file export only uses one thread and that the downloads are now multi-threaded. That explains it.

Hi Tradebuilder,

Thanks for the further information. That's correct - unfortunately the file writing cannot be parallelized. We'll look into whether we can make a few optimizations to make sure the application still remains responsive though.

Thanks.

Here is a tip for your programmer(s). When I am processing multiple large files I avoid the headache of thread protection management by giving all that to the OS. I do this by calling one program to do the file processing over and over until I have reached the maximum number of threads I want to use. So on my 32 core Ryzen 5950, I call it 30 times. Thus I can process huge files extremely fast -- I am literally using 95% of the resources on my machine while testing trading methods, creating Renko brick files and etc. When I call these programs I pass each one a unique command line so that it can get its instructions from a table. Anyway, not that I am expecting your programmers to do this, but it would be nice and it works really well. Even though I routinely create multithreaded software, this method is bullet proof and I have never had a crash doing it. Also, it is a much faster implementation than multithreading because the main program does not need to time slice and so all that overhead goes into processing data and not threads<g>.

If anyone there wants to know more, I would be glad to help out.

Hi Traderbuilder,

Thanks for the suggestions. We have sent you a private message (see top right hand corner to access) with a beta version that has a few performance optimizations. Appreciate if you can let us know if this helps alleviate the issue you mention with the responsiveness of the application.

Thanks.

Hi Tradebuilder,

As discussed offline, it appears the application update we gave you helped improve your multi-threaded performance significantly.

We have just released this as part of v1.9.7.0.

Thanks.

The improvement is almost unbelievable! I can export to files using 30 of my 32 cores and each is running the CPU core near max. I'm not sure exactly how much faster it is, but I can export at least 20x faster than I could before.

Thanks your for this incredible update!

Btw, I have not had one little issue with the beta.

Great news - thanks for the feedback!

FYI, the beta version you have will expire soon but you can download the latest version 1.9.7.0 via your download link. This latest version includes exactly the same functionality.

Thanks.