• 0

    posted a message on Official Threat-1.0 error reporting and discussion thread
    Yesterday in SSC i had profiling enabled while we were doing Hydross. The following times are from the combat only. Omen was disabled. (not sure why, but w/e ._.)
    3912ms Ace2
    2927ms Parser-3.0
    2816ms SpecialEvents-Aura-2.0
    849ms Threat-1.0
    So SEA is using more than 3 times as much CPU as Threat. Of course UNIT_AURA is fired an awful lot in this particular fight, but it just exemplifies how horrible SEA really is. It's very bad especially as the tank. On phase transitions, the entire raids gets a different debuff, that's probably 2 UNIT_AURA events for every raid member. I have to time my shield slam, but in the exact frame where I have to be as quick as possible, SEA causes frame lag. Not funny.

    Here's a little quote from the interview at curse.
    Antiarc: Well, Omen is obviously inspired by KTM, but I've attempted to improve on the design. The primary reason that Omen (well, its backing library, Threat-1.0) was written is because KTM brute-forces its threat estimates by polling a large number of values every so often. When we gained CPU profiling in WoW, I noticed that KTM was eating significantly more amounts of CPU time than any other of my mods, even while idle. There was a bit of a flamewar going on over this issue already, but what it basically came down to is that Kenco (KTM's author) didn't have any intent to change KTM's design to be more efficient, so I decided that I could do it better. Omen is empirically, by design, more CPU-friendly, which should improve the user's framerates, though that point is contested by Kenco. :)
    Posted in: Libraries
  • 0

    posted a message on Trying out Ace3 config
    Awesome, trying it out now.
    Posted in: Ace3
  • 0

    posted a message on Ideal UI demo
    I think you'd have to use that secure state stuff, and I've only seen a way to hide/show things. You could fake the sliding though by hiding the entire slider frame (including the handle), and show a copy of the handle in it's other state.
    Posted in: Addon Ideas
  • 0

    posted a message on Ideal UI demo
    Quote from Kameril »

    The collapsing is a great idea, unfortunately you can't properly collapse and expand secure frames such as unit frames and action bars in combat. Which is likely where you'd need them.

    You sure about that? I thought you can achieve this, as long as the user presses a button to show/hide the frame.
    Posted in: Addon Ideas
  • 0

    posted a message on efficient 2.4 combat log dispatcher lib
    Shadowed, let's say two addons are interested only in UNIT_DEATH sub-events. Now the large majority of sub-events are something other than death. So let's say it's not a match (event~='UNIT_DEATH').
    Without a library: Both addons are registered for COMBAT_LOG_EVENT, if it fires they check if event=='UNIT_DEATH' and return since it's not. (2 function calls, 2 equality tests)
    With a library: The library gets called, sees that registry[event] is nil and returns. (1 function call, 1 table lookup, 1 nil test)
    In this case, the library approach would win. You change one function call to a table lookup (which is a good deal), and save one test.

    However, if event=='UNIT_DEATH', the library would be slower, *but* in total this is outweighted by the fact that the miss frequency is higher than the match frequency.
    Let's say the two addons register for different sub-events, e.g. one for 'UNIT_DEATH', the other for 'SWING'. If none of the events is hit, you have the same runtime as before, 1 call+1 table lookup+1 nil test. The difference is that the frequency of matches got bigger. And if it's getting too big (e.g. when an addon registers for all sub-events), it becomes slower to use a centralized registry.

    So the question is: When exactly will the different approaches be faster?
    Other questions are: How much faster could the library approach possibly be? And how much slower could it be?

    The thing is: The library could estimate if it's faster or not with a given set of registered events. But what should it do if it's slower? Require the addon to implement fallback code, unregister all the events, and notify the addon? :)
    Posted in: Addon Ideas
  • 0

    posted a message on Trying out Ace3 config
    Quote from Nargiddley »

    Its a simple code change, its a reasonable amount extra to go into the spec for what a widget has to be to be usable. The widgets weren't designed with a clean API in mind as I diddn't expect them to be replacable. I've got the code ready to go in, just making sure the API is sorted before people start developing against it.

    Hrm, widget types (/classes) don't seem to support inheritance. Got your point.
    Anyways, are there any writeups on the AceGUI API? Design goals?
    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    Quote from Nargiddley »

    dialogControl (the proper name for dlgType) would be used as an attribute of an existing type, to change the widget that is used to represent it from e.g EditBox to MyCustomWidget. This would still be used by AceConfigDialog in exactly the same way as an EditBox would, so the custom widget would have to have the same API as an EditBox.

    Doesn't sound too complicated to implement, changing 'EditBox' to v.dialogControl or 'EditBox'. Any reason why this is not checked in yet? Just curious though, I'd be fine with "didn't have time". The discussion on jira went dry months ago, and the final word doesn't seem to be spoken. And in your post, you're using the word "would" instead of "will". :) Could we have some clarity on this issue?
    Posted in: Ace3
  • 0

    posted a message on efficient 2.4 combat log dispatcher lib
    Quote from dafire »

    I think this might be useful think if we can get everyone use that lib we can save some processor cycles..

    You wouldn't save anything if *everyone* uses that lib, as it would only introduce overhead to libs that are interested in every sub-event (the event return value from CombatLogGetCurrentEntry). You'd also introduce overhead if only one addon is interested in one sub-event. You may be able to save CPU cycles if more than one addon is only interested in a few sub-events. But it depends on how many sub-events. I suggest you write some benchmarks for the PTR to find out when it's actually useful to use such a lib, and post again when you're actually able to argue for your case. :)
    Posted in: Addon Ideas
  • 0

    posted a message on Self-generating code anyone?
    Quote from Tuller »

    So your unit frames are 'compiled' before they're run, essentially. Give me a framework + an example, and make the thing movable :P I swear oUF does something somewhat similar though.

    local Unitframe = CreateUnitframeConstructor('raid', raidoptionstable)
    unitframe.raid1 = Unitframe('raid1')
    unitframe.raid2 = Unitframe('raid2')
    ...

    This is just an example, I use a SecureRaidHeader to create the actual frames. But that's the basic way of how it works: CreateUnitframeConstructor is a function that returns a function. What it does is read the options from the table, (e.g. is there a mana bar? is there health text?) and create a constructor for the class 'raid', using loadstring in the process. So basically, raidoptionstable determines how objects of the class 'raid' will be constructed.
    Unitframe('raid1') then creates the actual frame, and the code to update them. Now if the options table said there's no mana bar, then no mana bar will be created, nor will there be any functions (closures) to update it. If there's no health text, the update code created for the UNIT_HEALTH/UNIT_HEALTH_MAX events would only update the health bar, but there's no code (not even an if-then-end) for the health text.
    That means: You have the feature of an optional health text, but if you choose to disable it, you have zero impact on the CPU usage at runtime, and zero impact on the memory usage. And even if it's enabled, it runs a little faster, because again there's no conditional like
    if optionstable.healthtextenabled then 
     --update health text
    end
    it would just update the health text, because the class (as opposed to the object) already knew there is one. So whether or not the feature is enabled, you save one table lookup, one test and one jump.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Making a static DataBase???
    You should try to find addons that do similar stuff. Addons that use slash commands for example. And addons that access a table like yours. Look at how they do it, copypaste stuff from other people's addons, make that work in WoW, then modify the code to do what you actually want it to do.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Self-generating code anyone?
    Quote from Seerah »

    So we are comparing apples to oranges then, you're saying?

    Err, sorry but did you even read my last post? :)
    Ok, I'll try to rephrase it a bit. First, I didn't start this thread to compare my oh-so-awesome addon to agUF and bash the latter because it's so slow. I was using agUF before I wrote Puppy, and I still like it, and I wrote Puppy do to pretty much exactly the same as agUF. I even copied the look of the frames. So except for the targettarget updating stuff described earlier, they have the same functionality. I then compared the CPU load at runtime, as both addons were configured to do the same thing. So I wouldn't call that apples and oranges.
    Still, agUF is capable of a lot more, mostly with regards to configurability. But the fact that there's a GUI instead of a hard-coded options table still doesn't make it very different in my opinion. What that GUI does is just write table entries. The runtime part of agUF then reads these options to determine behavior. What my addon does is read the options table, and generate the runtime code from it. That's the basic design difference I wanted to talk about.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Self-generating code anyone?
    spherific, nothing special there, I only listen to one or two events per unitframe, namely RAID_TARGET_UPDATE and either PLAYER_TARGET_CHANGED or PLAYER_FOCUS_CHANGED, so i simply use Frame:RegisterEvent().
    Quote from Bam »

    I got that feeling too. I have my own action bar addon. It's written for precisely my needs with hard-coded spells and macros. So it likely performs better than any other action bar addon. But it obviously lacks configuration stuff and isn't general enough for anyone else to use. :)

    Hehe, but that's exactly my point! Configurability and featuritis are the primary reasons why addons (programs in general) are slow: Even if you disable all the unused features, they are still slow, just because you could reenable these features.
    Self-modifying code is one way to avoid this performance impact, as you can tailor the executed code to just do what it's told, without one single instruction of overhead. "It's written for precisely my needs with hard-coded spells and macros", that sounds like a limitation, but it's not if that code was generated from a set of options.
    Right now, the only way to configure Puppy is to modify a table in the code. That's one of the reasons why I won't release it. I like the new AceConfig-3.0, so maybe I'm going to release a configurable version someday. Don't hold your breath though. :)
    Posted in: Lua Code Discussion
  • 0

    posted a message on Self-generating code anyone?
    Quote from Mist »

    I'm curious about your unit frames addon, and is the code optimization solely responsible for the 100x improvement? Or agUF is doing more stuff (aggro, range check, etc)?

    I just found the screenshot from a profiling session. The profiler is written by myself, it has no dependencies, and was instructed to only record CPU times while being in combat. The fight was Drekthar in the good old AV (1.5 months ago), so about 40 raid frames. Puppy is my unitframe mod. I only had Bongos2, agUF and Puppy activated, so only agUF is to blame for Ace2 usage.
    From the time spent in AceEvent-2.0 code you can tell that it's mostly the event handling stuff that is responsible for Puppy being faster.
    I'll repeat this test when agUF's Ace3'd version is released.
    Posted in: Lua Code Discussion
  • 0

    posted a message on TankPoints broken w/r55992
    Quote from Fionn »

    Any idea how to fix this?
    ...
    There's no need to fix this, Blizzard's UI displays values from a combat table against a lvl 70 mob, Tankpoints defaults to lvl 73. One lvl difference = 0.2%. You can read up the formulas in the Tankpoints documentation. Lower the level to 70 in the calculator and you got your "fix". ;)
    Posted in: General AddOns
  • 0

    posted a message on Self-generating code anyone?
    As Bam pointed out I was wrong and you can replace O(*) by constant. :>
    Posted in: Lua Code Discussion
  • To post a comment, please or register a new account.