[Rowne]

Gello Actually, I'd think it would be a bit different because the tables are processed on a different level to the namespace.

On loadup, for example, one namespace entry would be one thing to process. The rest would be executed by the parser in game.

However, with procedural, we'd be going bumpity-bumpity-bumpity along all those procedural names, processing the namespace before even getting into game. In fact, I'm partly convinced that login lag is caused by procedural pollution because users have reported that by switching from other AddOns to Ace(D) variants, they've seen incredible speedups in login times. In fact, this is one of the reasons I started pimping OO with fervour.

This isn't just about Ace for me but the fact that as far as I can tell, from all that I've heard users say, procedural is genuinely detrimental. I'm sure it's one of the reasons why Ace sees such incredible leaps in speed versus other systems out there right now.

This isn't to promote Ace because allow me to point out, all Ace AddOns are OO by default, so I'm considering this from an OO standpoint. If we're seeing great speed increases and the structure of the code really isn't that different then part of that increase must be to do with how we're actually doing the coding.

I wouldn't mind betting that a small part of those increases are down to OO. As I've said in the past, the official Lua programming book, Programming in Lua, states that procedural is a bad way of going about things and in no uncertain terms states that those who code in Lua should use OO, you can check out the book to see that for yourself.

I took all these factors into mind before I started posting here. So I gather that any results will only back up what I've said because the conclusion I'm trying to draw (even if it is a bit false) is that Lua seems to be designed to work in a more optimized way if coded in OO than if it's coded in procedural because every official Lua source I've encountered (including folks from ##lua on irc.freenode.net) would say that OO is the only proper way to do it.

So I'd like to see these tests done too because all these people can't just be piping up OO on a whimsical desire.

The thing is, I feel like the Warcraft community is getting left behind the rest of the World and doing things that primarily could be detrimental to Lua whilst those who've been using Lua long-time already know this. This is why I'm going to try and poke a particular Lua-nut I know of to stop by here and give us the exact lowdown. If anyone would know, he would.

I think my point is that it isn't so hard to imagine that Lua would be optimized to work with OO better than procedural and it's simply Blizzard that got it wrong, as opposed to Programming in Lua and the experts. I won't just leave it at my word though, as I said, I invite you to look around and I will poke the nut I know to see if he'll add a few words here because I'm sure that my suspicions have to have some kind of solid ground.

Belladonna Yup, all Ace AddOns since the inception of Ace have been OO. It was actually the foundation of Ace. The very reason I hopped on the Ace bandwagon was because at the time, I didn't know about OO in Lua and the procedural way of coding was driving me nuts. It was (from my point of view about my own code, originally) ugly, messy and just plain wrong. I felt like a litterer with every AddOn I released. Professionally it just wasn't a good way to code AddOns. Then Turan came along with Ace and said "Look at what I've made." Suddenly it clicked. Not only could I use OO in Lua but now I also had a framework. What it reminds me of to be honest (Ace that is) are the 'framework stubs' you can get for the Lua parser and for other environments.

I'd welcome your thoughts over on the wowace.com forums too because we're always looking for ways to optimize, we're all optimization nuts. If Blizzard gives us a new function, we jump on it like feral beasts who've not been fed for weeks (no, really, you should see us sometimes). There are folks who're constantly trying to improve the way things are run so if you see something that you don't think is efficient or if you know of a way to improve the way we use OO then please tell us because ... as I said, I'm very easily influenced by a good argument if it will result in cleaner code and a cleaner environment. S'why my code is almost bloody polymorphic in its very nature. Ever changing. So I'd like to hear what you've got to say. Ace always has its doors open to those who really want to show us better ways to make a moer efficient AddOn.

--- Edit ---

Another interesting point to make would be cumulative results, which could explain a lot. Sure, we've tested one function versus another one function but I don't think we're going to get real results until we compare 30 functions in one OO-object/table versus 30 procedural functions because what I'm thinking is that each time we create a procedural stamp, we're creating a base amount of 'baggage' for that stamp. Whilst one procedural might have less baggage than one table. 30 procedurals however might have far, far more baggage, being individual, than 30 tabled entries. I think these are the kinds of tests we need to run as they'd also explain the results the Ace community has seen.

Furthermore, it wouldn't be fair to count the table in each test either, the table should only be counted once because it only gets processed into a pointer once by Lua. A table isn't recreated every time it's called, it's only created on login or at the time of GC. So if we were to run a test, we'd only be able to consider the table element once and each function once. So we couldn't do table x 30 + tabled function x 30 because that's not how Lua porcesses. It'd be table x 1 + tabled function x 30. This is what I was trying to get at in the previous paragraph. Because I think it's stamp x 1 versus stamp x 30 and that's where the problem arises.

--- Further Speculation ---

I dare say that in fact, this would be much like how we'd consider a program. There's a reason programs like say, the GIMP, Miranda and so on have plugins. What would happen if we created a program and then made all of its plugins programs instead? All of the baggage that comes with a program versus a plugin would count for each program. So instead of 1 x program and 30 x plugins, we'd have 30 x programs and the baggage that each new instance of a program in memory would bring. So we'd actually be considering how the baggage of each individual entry would work versus a program with plugins. Certainly, if a program is going to be able to support plugins, it's going to have a slightly bigger stamp than a program that doesn't support plugins, but I find that if you load a program with 30 plugins instead of 30 programs, the memory stamp is much smaller.

This is the point I was trying to make above, that because we're not actually linking the footprints to one central point (a table), every new procedural function or global variable is a completely new instance and that instance has all the baggage that a new instance in the Lua environment that a new instance carries. Whereas in a table I strongly suspect that that baggage is lessened because it's shared by the table. Lua recognizes the table as a single instance and that the functions and variables that lie within aren't. So a tabled AddOn therefore is more like a program with plugins as opposed to lots of different programs.

--- Erm ... something more to add. ---

I want to apologize if I'm flooding you all, I'm a very 'thinky' person and I can speculate easily, that's why I want to see these tests run to see if my suspicions are right but I digress. I process things pretty quickly and I can tend to yammer on and on and on about things, it can be overwhelming. If I'm annoying anyone by going on and on about things too much, feel free to tell me to shut up for a bit or to make smaller posts, I won't take offense. ;p I know I can be gabby and I know it can be annoying even though I don't intend that. So ... I just wanted to say that. Now, back to our regularly scheduled OO discussion.