OO in blitzmax vs basic
BlitzMax Forums/BlitzMax Programming/OO in blitzmax vs basic
| ||
| Hi, OO was slower for a time when it was newly introduced. Does it result in slower execution of blitzmax code? See my findings on Globals in the hi-toro thread to see why my suspicions are raised. Please discuss... |
| ||
| How on Earth did you conclude that OO is a performance problem based on your experience with globals? For the record, OO was perfectly fast (Simula) until SmallTalk became synonymous with OO. (SmallTalk is still slow.) This wasn't helped by Java becoming synonymous with OO. (Java is still slow.) Turbo Pascal (which, in later incarnations, notably Delphi) was Object Pascal, was always fast. C++ may have compiled horribly slowly in the days of cfront but it never ran slow. All OO does is allow methods to be handled by indirection the way structured variables allow fields to be handled by indirection (e.g. Types in Blitz). A couple of clock cycles to dereference a.b (a\b) isn't seriously regarded as a performance issue, dereferencing a function pointer is no different at all. |
| ||
| Please discuss... Discuss what? A vague hypothesis based on a gut feeling? |
| ||
| You left out, "...and founded on false premises". |
| ||
| I guess I'm not the only person who's getting a kick out of this. |
| ||
| "OO is slow" is better phrased as "over-engineered OO by programmers who think every little thing needs to be an object is slow." Rather than doing the simple thing, some programmers tend to over-analyze things and come up with an elaborate class hierarchy where it's difficult to tell what's going on, let alone pinpoint performance issues. Simple, straightforward OO is no big deal. |
| ||
| Thank you for the only intelligent replies, junkster and pod :) |
| ||
| I scale my replies to match the intelligence level of the thread. If you really know this little about OO, maybe read a book before starting another thread... |
| ||
| OO itself is not slow but often OO includes a Garbace Collector ... and the first XY GCs that came up were slow so the whole software was slowed down ( so it is quite good to see that BlitzMax garbage collector doesn't do anything till you call flushmem :) ) |
| ||
| Honestly, OO carries a small overhead hit in that you have virtual function tables to parse through and things like that - but the difference on modern day processors is so minimal, it's safe to say there's really no speed loss. Garbage collection isn't an OO specific thing. Any language could use GC if it was designed to do so... |
| ||
| Or any programmer. |
| ||
| Most languages that support the OO methodology suffer a very small performance hit because they have to look up the correct function to call in an objects virtual method table instead of the compiler simply making a direct call to the function. The same applies to languages like Objective-C where messages (function calls) go through a runtime system, making them slower than direct function calls. The overhead is so small in the 'big picture' that it can be mostly ignored. If you are really interested in performance, then just use a function call for those bits that need to be fast. An OO language does not take any extra time to call a normal function than a language like C. Languages that run on virtual machines, such as Java and Smalltalk, may be slower because of the overhead of the VM. However, Java is not particularly slow. Some of the libraries, such as Swing, may be slow but the core language is not. Delphi's performance has never been too hot. Sure, it compiles very, very quickly, but runtime performance has always lagged far behind good C/C++ compilers. Its optmisations are a bit of a joke, and only in the latest version has it finally got inline function calls. Still, the point is that it does not matter, because it is perfectly fine for what it is intended for. It is better to worry about correct choice of algorithm. If the compiler is reasonably modern, a bad, or good, algorithm has a much bigger impact on application performance than anything the compiler does, or doesn't do, in the way of optimisation, or whether it is OO or not. |
| ||
| Offtopic, but: Delphi benchmarks right up there with C++ for most code. The two exceptions are floating point code, which Delphi does not optimize at all, and that objects are always heap allocated in Delphi whereas they are often on the stack in C++. But for straight-ahead code, they're very similar. (I use C++, Delphi, and Blitz, so this is speaking from experience.) |
| ||
| Thanks lads! Interesting stuff! This is what I like - refreshing views and no flamewars. Warren, If you haven't got anything nice or constructive to say then might I suggest you show some restraint? |
| ||
| Here is an interesting comparison of Delphi vs. various C compilers (http://www.realworldtech.com/page.cfm?AID=RWT071302231228). Delphi comes home slower than both MS and Borland C compilers, but does better against CodeWarrior. The article states that "a good programmer can wring about the same performance from a Delphi program", which implies that you have to put more work into a Delphi app to make it run nearly as fast. That is why I mentioned that finding a good algorithm is the major optimising step, not worrying what the compiler is doing. I also use Delphi extensively - it is my prefered platform on Windows. |
| ||
| skunk When you stop posting inane threads, I will show restraint. Again, read a book on OO. You seem to be really engrossed in what people are saying in this thread when, really, they're just explaining the basics of how an OO language works. |
| ||
| When you stop posting inane threads, I will show restraint. Warren, I am being humble and eager to learn. I find that when you take an active interest and are open minded, new things come to light. Inane new threads? Would you know about the important optimisation of using locals verses globals if I didn't bring it up? How about the loadAnimImage issue resulting in multiple state changes, (which skid has acknowledged he plans to look at) ? Combined, will provide actually useful speed gains in -your- game. These are not small speed gains. And now a small look into OO. I am approaching Blitzmax with fresh eyes, and an eagerness to learn. I will be using OO as much as I can of course, given it's usefulness... but avoiding globals and urging them to fix loadanimimage / state change issues! ... we've also spoken by email before, although I won't tell you who I am just yet :) |
| ||
| ... we've also spoken by email before, although I won't tell you who I am just yet :) Well, as long as you're being mature... Look, bottom line, BlitzMax isn't done yet. I have full confidence that Mark/Skid/etc will work out the kinks and we'll have something fully operational within a few months including a 3D module. I'm not concerned. |
| ||
| Now then children! :) Also, it all has nothing to do with accessing members of a structured type, as PodPerson would have you believe. Structure (type) members can be accessed directly by using an offset from the base of the structure, which is determined at _compile time_ because the compiler knows the size of the types in the structure. A custom type is probably stored as a pointer, rather than directly in the structure, so this has to be dereferenced to get to the actual storage for the object, but that applies to custom types outside structures as well. De-referencing refers to the act of accessing something through a pointer to that thing, at runtime. A virtual method table is a list of function pointers. A method is called by de-referencing this pointer to get to the actual address of the code to be performed. |
   |