First off, if you use my usage stats, especially the detailed reports or the JSON files and you have an opinion, but you don't have permission to post to this forum, PM me separately or post your thoughts to the GitHub issue.
I'm in the process of completely rewriting the scripts I use to generate usage stats. The system that we have now works, but just barely--it's horribly written, slow as molasses, about as sturdy as a piece of tissue paper and an absolute migraine to maintain.
I just finished a "proof of concept" release of the new system, which is able to generate the basic usage rankings for all non-mod (read: Gen VI) tiers. It's slow--not significantly faster than the old system--but it's decently resilient, and most of the configuration files get scraped straight from Pokemon Showdown, so maintenance is a piece of cake.
My original plan was not to switch over to the new system until I'd finished building out the full feature set and done significant work optimizing and performance-tuning. But more and more, I feel that keeping the old system up-to-date and running is a significant waste of my extremely limited time and energy.
So what I'm asking is this: what is the absolute minimum set of analyses that people can live with when it comes to the usage stats? Do people actually use the moveset stats or the stalliness analyses? Do people find checks & counters or teammate stats actually useful, to the point that they'd be seriously bummed if they went away for a while?
I'd also like input as to performance benchmarks. That is, if it takes 30+ days to process a month's worth of logs, that's obviously a nonstarter, but what about 1 week? The current system can process a full month of logs and generate reports in about 4-5 days (reports end up being delayed by needing to fix bugs and rerun). Do I need to make sure I hit that target?
Zarel, I'd also like your input in terms of resource consumption. The current system runs mostly single-thread (and log-reading, which takes a while, doesn't use up significant CPU), and a month's worth of processed logs takes up about 14GB of disk space. A month of data from processed logs under Onix v0.1 exists as a ~60GB sqlite database file, and the processing is probably a bit more CPU and disk-intensive, plus I'm about to throw in multiprocessing, so if this is a no-go for deployment on the server, let me know.
I'm in the process of completely rewriting the scripts I use to generate usage stats. The system that we have now works, but just barely--it's horribly written, slow as molasses, about as sturdy as a piece of tissue paper and an absolute migraine to maintain.
I just finished a "proof of concept" release of the new system, which is able to generate the basic usage rankings for all non-mod (read: Gen VI) tiers. It's slow--not significantly faster than the old system--but it's decently resilient, and most of the configuration files get scraped straight from Pokemon Showdown, so maintenance is a piece of cake.
My original plan was not to switch over to the new system until I'd finished building out the full feature set and done significant work optimizing and performance-tuning. But more and more, I feel that keeping the old system up-to-date and running is a significant waste of my extremely limited time and energy.
So what I'm asking is this: what is the absolute minimum set of analyses that people can live with when it comes to the usage stats? Do people actually use the moveset stats or the stalliness analyses? Do people find checks & counters or teammate stats actually useful, to the point that they'd be seriously bummed if they went away for a while?
I'd also like input as to performance benchmarks. That is, if it takes 30+ days to process a month's worth of logs, that's obviously a nonstarter, but what about 1 week? The current system can process a full month of logs and generate reports in about 4-5 days (reports end up being delayed by needing to fix bugs and rerun). Do I need to make sure I hit that target?
Zarel, I'd also like your input in terms of resource consumption. The current system runs mostly single-thread (and log-reading, which takes a while, doesn't use up significant CPU), and a month's worth of processed logs takes up about 14GB of disk space. A month of data from processed logs under Onix v0.1 exists as a ~60GB sqlite database file, and the processing is probably a bit more CPU and disk-intensive, plus I'm about to throw in multiprocessing, so if this is a no-go for deployment on the server, let me know.