It does, but the UI doesn't update until you actually scroll the list. Move the mouse over the list and scroll the mousewheel, even if the list doesn't look scrollable; that should force it to update.
I'm having the same issue, and scrolling does not appear to help.
Tried to reinstall the addon as well as deleting my settings (.lua-files), with no improvement.
Other addons all include all my Sharedmedia, so this is isolated to Recount in my case.
I'm having the same issue, and scrolling does not appear to help.
Which SharedMedia package(s) are you using? Have you tried deleting Recount completely and reinstalling it from a fresh download? Are you using the latest release version (the one you see on curse.com) or an alpha or beta version (ones you can see on wowace.com)?
- Error on deletion. It is now delayed until the next out of combat opportunity.
Shouldn't you instead eliminate unnecessary subtables to make wiping out works faster? At least .Details. step is clearly redunant. It was in the patch I've submitted some time ago, but you've choose to ignore it because "you can't be bothered for every little patch when you work on addon for millons of people". Now Blizzard's own limits come to bite you.
Another temporary solution would be is to simply de-attach table instead of wiping when you're in battle and attaching new, empty table for new structure instead. Keep link to deatached unprocessed table somewhere and wipe it with your custom methods after end of combat.
Also, quick review of :GetTable show that you get first table from list and then tremove(Tables,1). This is bad. If you look at implementation of table.remove, it shifts all element one-by-one to new positions. Removing at [1] is the worst case for it. Pick up table at Table[#Tables] instead and then nil that index.
Shouldn't you instead eliminate unnecessary subtables to make wiping out works faster? At least .Details. step is clearly redunant.
The problem is that we do not know what the performance cut-off is to avoid the script too long error. That is the real problem.
The minor problem is that all the optimizations are very minor compared to the overall data volume that does need to be deleted. I.e. these are cosmetic at best and don't solve the core issue, which is guaranteeing that the error does not occur.
It was in the patch I've submitted some time ago, but you've choose to ignore it because "you can't be bothered for every little patch when you work on addon for millons of people". Now Blizzard's own limits come to bite you.
I don't accept your patch because it does not actually solve the problem in question.
Another temporary solution would be is to simply de-attach table instead of wiping when you're in battle and attaching new, empty table for new structure instead. Keep link to deatached unprocessed table somewhere and wipe it with your custom methods after end of combat.
That is cosmetically different from what is the current solution.
Also, quick review of :GetTable show that you get first table from list and then tremove(Tables,1). This is bad. If you look at implementation of table.remove, it shifts all element one-by-one to new positions. Removing at [1] is the worst case for it. Pick up table at Table[#Tables] instead and then nil that index.
GetTable is used to reset the data in the actual bar display lines. The cost of the call to the GetTable function in the deletion routine has an upper bound of the number of rows in the main window display. This is trivial and unproblematic and can easily be done in combat. In fact it is routinely done in combat in Recount due to battle display switches.
That is, the part you are proposing an optimization for here is not what is substantially responsible for causes long script run-time. Deleting combatant data not bar lines is what is costly. And given that combatant data scales with recording time there is no way to construct an upper bound to the data via pruning strategies.
There are some simple guidelines for how to optimize. The most critical question is: Does it solve the problem? If no, it's a waste of time. If you do want to find tangible optimizations understand what the critical costs are and if possible optimize them. (In some circles this is known as "profile before you optimize"). Don't optimize randomly or small parts that are known to have trivial impact on the overall performance. Doing those may make us feel like we did something. But really we are still only wasting our time.
Just want to chip in that about the limit to execution time (on PC, it might be different for Mac) has been found to be ~200ms in combat, 150ms being considered 'safe' (at this moment, Blizz might change it).
This is not my work, just remember reading about the testing on some ticket comments (exact ticket escapes me atm, but the numbers stuck in my head)
It's just an aside, not exactly pertinent to the last couple posts although I think I remember that rowaasr13 suggested optimizations mainly had to do with CLEU handling and had been shown to be inconsequential through actual profiling the last time around.
I have to say that was a rather long time to be lurking to get a final stab in :P
Just want to chip in that about the limit to execution time (on PC, it might be different for Mac) has been found to be ~200ms in combat, 150ms being considered 'safe' (at this moment, Blizz might change it).
This is not my work, just remember reading about the testing on some ticket comments (exact ticket escapes me atm, but the numbers stuck in my head)
Interesting. I'd love to read the actual work. Not so much for deletion but in order to make the config window more robust for in-combat use.
I have a quick question about the number formatting.
I have chosen to have it set to 'Short'. When I have the 'Damage Done' shown in the main window the damage is shown in short, but the DPS in brackets next to it is shown in its full number.
Iv addad a screenie so you can see what I mean. You can see on the config window example it shows both numbers in short format, but on the actual window the DPS is in full.
On the very first page of this thread there is an example picture that has both numbers shown in short format and thats what I am trying to get it to look like. Is there something else im missing to make it show all numbers in short?
That's a good observation. It used to not be necessary to shorten DPS numbers because the number of digits were low and averaged hence static. The totals grow with the time of play and bounding their representation made sense much earlier.
Anyone objection to linking the short display also into the DPS numbers? The problem here is that some people may actually like the fine detail of their DPS numbers (though that fine detail is basically worthless) and liking them may not be universally seen as the right move. I'd love to not clutter the config window with a separate option though.
Perhaps I can think up a mixed solution where DPS numbers are guaranteed to show 4 digits or something, no matter where the rounding point will fall.
Let me know your preferences, in short:
Link short setting over to DPS numbers (hence shortening them in the same way)
Floating DPS number representation guaranteeing 4 digits to be shows but shortening more digits.
Keep as is, allowing full resolution of DPS numbers
I'd prefer #1, as I don't really care to ever see anything other than 542, 4.8k, 52k, etc. as the difference between, say, 52123 DPS and 52132 DPS is not worth the screen space it takes to show it. Those who want to see the full number are free to turn off number shortening and see it.
I agree with Phanx on this. Those that want the fine granularity will likely not have any numbers shortened. So linking the DPS numbers to the setting makes sense to me.
For whatever reason Recount is continuously causing me errors. It freezes the game at startup sometimes which requires me to close down, delete recount/wtf, reinstall it and try again.
OR, most recently, it's causing me to not be able to load into zones, rendering the client incapable of loading fully and I have to relog. I made a ticket about this, there are many about this or similar problems but with no response.
I'm at my wits end. I hate skada, but Recount is causing me SO many problems.
Not knowing what errors your are getting and stabbing into the dark: Manually delete more, make sure that your event-based deletion options are set such that you delete frequently. Make sure to start with a clean slate with respect to wtf.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
(I fixed my previous problem, thank you for the help!)
There is no way to change the font size independently of the bar size, and no way to hide the realm names.
I'm having the same issue, and scrolling does not appear to help.
Tried to reinstall the addon as well as deleting my settings (.lua-files), with no improvement.
Other addons all include all my Sharedmedia, so this is isolated to Recount in my case.
Which SharedMedia package(s) are you using? Have you tried deleting Recount completely and reinstalling it from a fresh download? Are you using the latest release version (the one you see on curse.com) or an alpha or beta version (ones you can see on wowace.com)?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAnother temporary solution would be is to simply de-attach table instead of wiping when you're in battle and attaching new, empty table for new structure instead. Keep link to deatached unprocessed table somewhere and wipe it with your custom methods after end of combat.
Also, quick review of :GetTable show that you get first table from list and then tremove(Tables,1). This is bad. If you look at implementation of table.remove, it shifts all element one-by-one to new positions. Removing at [1] is the worst case for it. Pick up table at Table[#Tables] instead and then nil that index.
The problem is that we do not know what the performance cut-off is to avoid the script too long error. That is the real problem.
The minor problem is that all the optimizations are very minor compared to the overall data volume that does need to be deleted. I.e. these are cosmetic at best and don't solve the core issue, which is guaranteeing that the error does not occur.
I don't accept your patch because it does not actually solve the problem in question.
That is cosmetically different from what is the current solution.
GetTable is used to reset the data in the actual bar display lines. The cost of the call to the GetTable function in the deletion routine has an upper bound of the number of rows in the main window display. This is trivial and unproblematic and can easily be done in combat. In fact it is routinely done in combat in Recount due to battle display switches.
That is, the part you are proposing an optimization for here is not what is substantially responsible for causes long script run-time. Deleting combatant data not bar lines is what is costly. And given that combatant data scales with recording time there is no way to construct an upper bound to the data via pruning strategies.
There are some simple guidelines for how to optimize. The most critical question is: Does it solve the problem? If no, it's a waste of time. If you do want to find tangible optimizations understand what the critical costs are and if possible optimize them. (In some circles this is known as "profile before you optimize"). Don't optimize randomly or small parts that are known to have trivial impact on the overall performance. Doing those may make us feel like we did something. But really we are still only wasting our time.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis is not my work, just remember reading about the testing on some ticket comments (exact ticket escapes me atm, but the numbers stuck in my head)
It's just an aside, not exactly pertinent to the last couple posts although I think I remember that rowaasr13 suggested optimizations mainly had to do with CLEU handling and had been shown to be inconsequential through actual profiling the last time around.
I have to say that was a rather long time to be lurking to get a final stab in :P
Interesting. I'd love to read the actual work. Not so much for deletion but in order to make the config window more robust for in-combat use.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumRemembered; the reference was in this ticket comment to AceTimer-3.0 (before the conversion to use the animation system)
I have a quick question about the number formatting.
I have chosen to have it set to 'Short'. When I have the 'Damage Done' shown in the main window the damage is shown in short, but the DPS in brackets next to it is shown in its full number.
Iv addad a screenie so you can see what I mean. You can see on the config window example it shows both numbers in short format, but on the actual window the DPS is in full.
On the very first page of this thread there is an example picture that has both numbers shown in short format and thats what I am trying to get it to look like. Is there something else im missing to make it show all numbers in short?
Anyone objection to linking the short display also into the DPS numbers? The problem here is that some people may actually like the fine detail of their DPS numbers (though that fine detail is basically worthless) and liking them may not be universally seen as the right move. I'd love to not clutter the config window with a separate option though.
Perhaps I can think up a mixed solution where DPS numbers are guaranteed to show 4 digits or something, no matter where the rounding point will fall.
Let me know your preferences, in short:
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBtw, there should be a "not" in your sentence about the config window clutter ;)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOR, most recently, it's causing me to not be able to load into zones, rendering the client incapable of loading fully and I have to relog. I made a ticket about this, there are many about this or similar problems but with no response.
I'm at my wits end. I hate skada, but Recount is causing me SO many problems.