Ok, if I'm reading this right, please do correct me as I'm not trying to start a flame war here. I'm just looking for some answers to some questions.
Is it me, or has Fubar gotten more bloated now that Rock is involved? From those screens, it looks like it now takes twice as much to run Fubar than the new Titan that's in the works. And this is both without any modules added! So I ask this, which one is more efficient at this point?
Now I know some people are gonna respond with something like "um, duh, look at your own screens!", but like I said, I'm asking cause I'm sure I may be missing something. Like Rock not actually being required (though I tried it without it and got an error).
the thing that seams to drive up the memory usage is the framework fubar is set in which is rock. as such fubar by itself is more efficient by itself since it uses the same framework as some other well known addons (cartograph,pittbull,parrot,cowtip) and it provides the same framework to all addons that want to hook into fubar.
so there is yes and no fubar iself is smaller than titan but it also has a backend system which is bigger than titan because this backend system was designed for any addon that choses to use it instead of just fubar itself.
Notice how in that screenshot, Titan Panel with no plugins is using 3x as much CPU/sec as Fubar with all the Rock libraries added up together (about 0.7 vs 1.9).
It would appear to me that Titan Panel is still being as inefficient as it always was, lagging users to hell with lower FPS by performing completely unnecessary updates and checks every frame with its OnUpdates. If the author of Titan Panel refuses to acknowledge that his code is inefficient or flawed over 2 major code releases, there is nothing we can do, and most users will stick with Fubar due to its performance.
LOL look at the 4th Column, CPU/sec.. Idling, titan pannel is at 1.9 and fubar is at 0... i'd look at that..
Throwing Rock's Config into the mix is just pain wrong. ALL PRE Gen UI systems eat memory like a hog, no way arround it. Look at AceGUI3 - it's a mem hog once it's used. It's an efficent memory hog, but one none-the-less.
You also have to think about how customizable FuBar is. Draggable, resizable, recolorable, can change textures, etc. FuBar was not made as a *replacement* to Titan, but rather an *alternative*. Looking at pure memory stats doesn't mean anything. The posters above speak truth as well.
1. FuBar may not utilize everything in the libraries it needs to run, but it shares those libraries with other mods - if you have multiple mods running on the same libraries, memory usage is cut down. (If you just have one mod running on all of those libraries, it looks like too much, as you already have seen.)
2. Titan was always a little sloppy performance/code-wise. Check your CPU column for that. (Also note, that enabling CPU profiling uses more memory in general.)
3. FuBar is way more customizable than Titan. Those options need code, and that means memory.
4. Static memory is meaningless. It doesn't matter how much memory your UI uses as long as your system can handle it and you're not taking a performance hit. The 3rd column that Bam mentions is how much the memory changes for your mod per second (ie, not static). It doesn't matter if one mod uses .5MB and another uses 1MB - just as long as they're doing what they're supposed to do and you like them.
Well there's your answer, split up a bit. The memory usage isn't going to affect performance. It's simply too low to do so, even on a shitty computer. What does matter here--the CPU usage--Titan is a damned hog on. And if you run through this with some plugins I'll bet it'll be even higher still, towering over FuBar (and I'm sure you'll see the same trend with garbage creation). Factor in the fact that a lot of what the libraries have to do for FuBar will handle a lot of FuBar plugins, as well as a some other mods (more are added everyday!), and Titan doesn't compete.
Even after this though, FuBar remains, as far as I know, the more configurable and featureful of the two--by far.