Quote: "I think it has to do with all the .dll calls. I'm no expert, but in 2.0 you're calling a function that in turn calls a .dll function. That's 2 calls just to do one thing. In some cases, with auto-assignment, it also calls another function for the numeric assignment. If you aren't calling all those functions, it runs super-fast on my machine (compared to 1.0). But as soon as I start calling functions within my game, it slows down significantly-- not too slow, mind you, but very noticable."
It's not because of the .dll calls, DBPro makes calls the exact same way, and .dll calls are extremely fast anyway. The only reason it should be any slower is because of the new thread-safe feature. Every time you call a command it has to acquire a lock on a mutex (or something similar) to make sure only one thread can call a command at a time.
Some commands (such as wrapvalue and other maths commands) are already thread-safe so they will get faster once mistrel has had time to go through and sort out which commands don't need any extra work to be thread-safe. My main point is that there's no fault in the design of GDK which makes it slower, performance is just something that will need to be refined.
Even so, I haven't run into any performance problems myself with any of the things I've ported to GDK from DBPro.
[b]
