You guys seem to have just a ton of RAM. I just can't imagine having that much RAM, but it could be because I'm still using a 32 bit OS (XP SP2). Would I see an increase in FPS if I went to a 64 bit OS with more RAM, which is dirt cheap these days? I currently get about 20-30fps in combat at full settings (minus high quality shadows) at 1920x1080.

Though I'm thinking that has more to do with running in windowed mode with an appreciable number of mods running, including recount. I only have 2 gigs of DDR2 RAM currently.

For spell detail, you can turn the silder all the way down to the "D" and still be able to see full duration consecrates, death & decays & so on. Any lower than that, and you start cutting those out.

I'm not convinced this is true. The client does receive all the activity data, but the combat log (which Blizzard implements as an addon) doesn't automatically process that data. It only processes the data for the game events (COMBAT_LOG_EVENT) that the current filter is registered to respond to. So if you have a combat log filter that doesn't respond to any of those events, it won't trigger the code to extract and display the information.

Also, it looks like the combat log processes events it's registered for even if the log is not being shown. To see this, you can switch from a chat tab to the combat log when the filter is set to show everything. Everything that happened while you were in the chat tab gets displayed instantly. But if you switch filters, you can see the combat log go back and refilter the last 5 minutes' worth of information.

I assume you already tried dropping shadow quality and clipping distance.

Try running WOW in OpenGL mode. Change the shortcut to "wow.exe -opengl". This was a dramatic improvement on my old computer, a 3.6Ghz C2D with 2GB RAM and a 8800GTS 640MB.

On my new computer, a core i7 920 at 4Ghz with 6GB RAM and the same videocard, I don't have any FPS issues at all in directx mode. The engine changed in WOTLK and nobody knows why these slowdowns occur. WoW certainly wasn't CPU bound on my old box.

Yes and no, Naxx is old content so the geometry is the same, also you run with 25ppl instead of 40, the only thing that changed was the DK spell stuff. So its that or they relly messed up the engine.

Anyway about the combat log it holds some true Iam atm raiding and I removed every filter including things "Done by" and "Done to" in self and I saw a significant FPS increase just did Thadius and felt way more responsive.

WotLK is a pretty big memory hog, at max settings the WoW client can use over a gig on it's own, when you include background apps and the OS, 2GB of RAM really isn't enough.

I suspect at the very least, that there's an inherent "peek" operation going on in most mods to at least check the event type (which happens to be the first flag on each combat line as far as I know) and that in itself is likely an intense operation to keep things running at real-time. I doubt there's an underlying engine that "peeks" once and doles out the lines of combat to applicable mods, but at best I'm offering conjecture at this point. Perhaps someone who has written one of these popular mods can comment on the "best practice" vs "commonly used practices" and how performance is impacted as a whole.

Regardless, the strongest correlation that anyone has ever drawn is that if anything depends on combat log data, then culling that particular mod is almost always a performance increase provided you were originally CPU bound. The evidence that everything "gets worse" by an order of magnitude in 25-mans seems to support this, especially in the case of AoEs or any type of multi-target hits multi-target setting. You can control for rendering/graphics performance hits by simply staring at your feet in these cases.

Graphics are usually a "static" problem in so far that every graphic object on the screen detracts from your performance, so logic would state that the more objects on the screen, the worse it gets, however staring at your feet should eliminate these variables and leave you with the raw computational problems. Blizzard used to performance test at customer support by asking players to stare at the sky in the middle of Shattrath and report their FPS.

Also, for those who were not around for the audio problems in TBC, a fair amount of andectotal evidence came up that the audio/sound engine in WoW is also fairly processor intensive (a lot of the performance threads were tracking FPS increases via disabling sound, but audio drivers were not controlled very well at the time of the reports). The off-hand conclusion was that that having on board sound used enough of your raw processor to impact your total performance, but those with audio cards tended to not see performance drops at all from disabling/enabling sound. This makes sense from a hardware point of view, as half the point of a sound card is to use more suitable/dedicated CPUs for audio processing.

If you are doing the run's /combatlog, then I would suggest turning off antivirus file access scanning of *.txt files, for one.

The /combatlog is an entirely seperate process that's independent of anything you do in WoW. Filtering your log will not interfere with the process. There's really nothing you could do to effect /combatlog in general, and is actually one of the points I failed to mention above which further supports a server->client(s) transmission and then a separate process paradigm.

/Combatlog itself is a somewhat performing task as well, as I believe it writes to the file in chunks, but I'm unaware of when the chunks get dumped to the text file. Thus, there's probably a memory component (but who cares about memory), but more importantly: a periodic disk access component. I'm unaware of the intricacies however, and tend to only see a single digit FPS loss when I run /combatlog with my usually fragmented 7200 RPM drives, and that's only in 25-mans.

I could be wrong here as I don't claim to be a LUA expert - Since WoW is event driven, that should pretty much be exactly what's going on under the hood. Functions in addons are registering for notification when events arrive at the client, and then the event parser within the client is notifying everyone that hooked into a particular event. If you have addons that are hooking into tons of shit that they don't need, or that are hooking into events that fire frequently (BAG_SLOT_UPDATED used to fire stupidly often as I recall, which made bag sorting addons perform horribly), then the addons will require additional CPU time to run their event callbacks.

[e] In case I misunderstood what you were saying - the addons themselves shouldn't be inspecting every single event. Rather they register with the client, which keeps track of which callbacks are interested in what event types. When the client reads that event type at arrival, it runs through the list of interested listeners and instructs them to execute their callbacks.

Ffor me if I have Firefox running (in fullscreen in game) and I am in a raid (ONLY raids...normal world is fine), I get very bad fps and then d/c issues. Some thought it might be many tabs open, but all I had open was EJ or Wowhead. WoW, Firefox and Ventrillo are the only things I ever run on the system. I found closing Firefox helped tremendously. I wouldn't post as I assume most close just about everything running on their system, but a browser is such a common tool these days that I felt it could be overlooked.

Now, as for why the two behave so poorly together for me, I've got no idea.