by Guest on 2020/11/16 10:00:20 PM
When I drag around the Tixati window and my mouse polling rate is >=500 it will be very slow and laggy, putting the mouse polling rate in my control panel to 250 or lower fixes this. I've had this problem with other applications before (CPU-Z), but it seems newer versions fixed this.
I hope this can also be fixed for Tixati
by Guest on 2021/05/21 04:22:43 PM
The simple answer is that Tixati needs rewriting with a separate thread for the interface. Back in the day I used to write assembler software, and it was best practice to assign a thread JUST for the interface, that could run concurrently with whatever processing the software was doing. That way the interface NEVER lags or stops responding when the processing thread is overloaded or waiting on disk responses.
Tixati is hamstrung sometimes by the fact that it's very disk-intensive. Using slower spinning disks, where there are lots of torrents or requests, and especially when doing BIG operations like verifying downloads or creating the full file images on a torrent start, it slows to a crawl waiting for the disk to respond, and since that thread is ALSO doing the interface response, it just hangs waiting for disk operations to complete. That's poor software design, I'm afraid. It may be that it's also not doing async disk operations, which is the best API for disk writes that releases control to the OS until the write is complete, so it can work on other things until the OS responds that the write is finished. The improvement from that to overall speed of any disk-intensive software is substantial.
I've also written elsewhere on this forum that there's a MAJOR stupidity in the way incoming data writes are processed, all coming into a SINGLE disk cache location and then each individual completed piece being copied from there into the correct location in the fileset. This means Tixati is doing TWICE the disk writing it needs to, as it's easy to write the data into the output file directly without this separate construction elsewhere, so it's highly inefficient. It also means that nearly complete pieces are useless to the downloader, when if they are contructed in situ inside the output file a 99% complete piece will present just a tiny glitch to a video player, rather than a piece-sized hole that'll never be filled as Tixati won't write incomplete data. AND allowing incoming data to write direct into the output files, which may be on multiple user disks, means the TOTAL disk bandwidth of Tixati increases substantially instead of being constrained by the bandwidth of that single cache disk, which is a bottleneck. And don't forget, if that cache disk is an SSD, then all the tiny writes Tixati does saving pieces and completion data is going to kill it VERY fast, even if it reduces the bandwidth bottleneck. So concentrating ALL incoming data writes into a single cache disk is VERY dumb on many levels.
I wish they'd fix these glaring issues in the file subsystem. No doubt the program is very effective now on the Bittorent side, but it could be far more efficient by doing far less IO, and this would directly improve the interface response even if they can't implement a thread just to handle that, which would eliminate lag completely.
