• 0

    posted a message on ag_UnitFrames (Release 7/19/2006) alpha version
    Quote from Kyahx »

    Quote from Miles »

    About the buckets / bulk updates: in my opinion, unitframes should be written efficient enough to keep react on health changes instantly, not wait 0.2 seconds and *then* show me what happened.

    You obviously have a very tiny grasp on the implecations of non-bucketed events, and don't understand why they came about in the first place. PerfectRaid was the first raid unit frame mod to use this techinque (in fact, PerfectRaid was initially created as a demonstration to prove that Bucketing events works, and works wonders.)

    Sure, your computer can handle it, but how much KB/s increase do you have? How does that affect slower computers?

    Why do you think so much lag is associated with raiding, UNIT_HEALTH is fired (a single event) for EVERY time someone takes damage, drinks a potion, is healed, etc... This also fires for any pets in the raid as well. Go profile Ag_UF (in a full 40-man raid) against CT_Raid or even the Blizzard default raid UI. You'll see a massive differance. A differance in how big your KB/s increasing rate is, which in turn affects your garbage collection (also know as the semi-seccond 'hiccups' that people associate with raiding). All this churn affects your FPS as well.

    You want unit frames that are coded to efficently handle all this tidal wave of events? You already have it, its the entire reason that bucketed events are part of AceEvent, a core piece of Ace2.

    You want frames that update instantly, faster than the human eye can even notice? Pull out your default raid frames or go install CT_Raid. Enjoy your lower FPS and increased KB/s while you're at it.

    But please...don't try to dismiss 'facts' about things you know very little about.

    Fine. Let me start by saying that I have read and understood the inner working of AceEvent. Please understand that buckets are nothing more than collectors for events, and it calls the handler with a table on a throttled rate instead of on every fired event.

    The first obvious flaw: it waits for at least the specified time before it notifies the event handlers. With 0.2s, that is 1/7 Flash Heal of lag.

    Secondly, you obviously don't have any idea how a garbage collected heap works. Using terms like KB/s makes that quite clear. In a nutshell, instead of forcing the programmer to keep track of changes (malloc and free, new and delete), in a garbage collected heap you can allocate objects (tables in lua) without paying attention, and the wasted space gets recycled someday. Note that variables on the stack have nothing to do with that and as a result, calling UpdateHealth 100000x times will not create a single byte of garbage with your current code - there is no table creation involved.

    The third flaw is that you claim that you cannot see a 1/10th second delay. That is obviously false. Try playing wow on 10 fps, and wonder why every game aims for the magical number of 30 (rts, rpg) or 60-100+ (shooters). If something happens with my raid - I want to know that asap, and not 0.2 seconds later.

    And finally, the bad performance associated with non bulk updates is caused by the event handler itself. It doesn't check the UnitID that triggered the event, so everytime *any* hp changes, all 40 bars updates itself. Rule #3: Profile (or just read, ffs) the code first, *then* optimize (fix, in this case).

    I, and my guild is pretty happy with an instanly responding raid frame, without any *measurable* performance hit. Next time, do your homework first, and then start pointing fingers. And make sure you actually measure the cpu load / time spent / gcinfo() in those methods instead of pulling numbers out of thin air.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames (Release 7/19/2006) alpha version
    For the non bucketed update, replace the ag_UnitClass.lua with http://digibites.net/files/ag_UnitClass.lua.

    Just out of curiousity, why do you register every single frame as an event handler instead of going the 'procedural' way and update the right frame in a list? Getting OnUpdate called 40 times only to return instantly if the current frame didn't changed seems like a major waste to me.


    About the buckets / bulk updates: in my opinion, unitframes should be written efficient enough to keep react on health changes instantly, not wait 0.2 seconds and *then* show me what happened.

    But that's not always the case, so you may try to cull updates that happens more than once a frame, but look at the code of AceEvent, and ask yourself: is the theoretically slightly better performance worth the overhead of bucketing with 0.05s (20 times/sec)? The most changes I have seen per second is 4 hits on our MT in a second (mob instant attack procs and skills) - why not process all 4 of them the instant that happens?

    The best way to do the culling is with a Addon Global event handler for health and power changes, and track what happened in a semi-fixed size list of 40 units (I don't know about the underlying C implementation, but I bet it's grow-on-demand vector/arraylist). On each OnUpdate, process only the names occuring in the list and clear it. WoW Widget API calls are slow compared to pure lua, so this method keeps the amount of Set*'s to the absolute minimum.

    If you're lagging badly, add a minimum time since last update timer to the tracking list, and skip updating the same frame more than [number between 2 and 5] times a second. This way you won't spam-call the external API. But always process the updates directly at the first event when you set a timeout, so at least the players sees the first change directly.

    [edit] Digged up an old slide:

    General Rules for Optimization

    Rule #1 - Don't.
    Rule #2 - Don't do it yet.
    Rule #3 - Profile First.
    Rule #4 - Optimize the algorithm.
    Rule #4.5 - Cheating is often more efficient.
    Rule #5 - GOTO 1.

    #3 is a bit hard to do in lua, but I've modified TraceEvent to monitor CPU load (left as excercise for the reader, hint: do it smilar to the way it profiles gc-pressure). agUF (/trace aUF) isn't causing trouble even in direct update mode, as far as I can see.
    Posted in: Unit Frames
  • To post a comment, please or register a new account.