On 25 March 2010 18:35, Andreas Raab andreas.raab@gmx.de wrote:
On 3/25/2010 9:04 AM, Igor Stasenko wrote:
drawable := OpenGLSurface newIn: (0@0 corner: 10@10). ogl := AlienOpenGLLibrary uniqueInstance. alienMethod := ogl alienMethodNamed: 'glGetError'. time := [1 to: 1000000 do:[:i| error := GLEnum new. alienMethod primFFICallResult: error. ]] timeToRun. drawable close.
i don't know how to load this code, could you put error := GLEnum new. out of block and run it again?
No, because you're returning it and you can't share error code instances (it's like saying that something that Point>>z:y: should just return the same point for each call :-) It's fine to cache the call that way since it's internal to the library but not for the return value.
Well, it is up to the caller to decide, whether he wants to create a new instance for every return value, or use a single one. For glGetError, this is fairly acceptable, because you can hide the GLEnum instance inside the class which implements glGetError.
It is expected to see that marshalling/converting types takes most of the time, while rest should be same, because it straightforward: push arguments, make a call and return result. So, at some cases (not at all), one could prepare arguments and return value holder and then use it in calls, avoiding allocating& converting them each time.
But what you call "preparing arguments and return value holder and then use it" is marshalling. Moving it into the caller doesn't actually make it faster. And how much time do you want to spend optimizing your use of callout facilities vs. actually writing the app?
For instance, when you passing a string (char*), one may use a CString object (a null-terminated String), and pass it into Alien without conversion, while FFI allocates a null-terminated strings on heap, copying String contents to that buffer and then using them as arguments to a function.
The FFI can do the same but it's mostly pointless. If you have a Squeak string you can convert it to a C string (ExternalData) and pass it into an FFI call.
So its hard to say, which way is better.
There's no doubt in my mind. Absolutely nobody is going to spend time optimizing their callout interface manually. They use the stuff that's there. Go look at AlienOpenGL. Go look at Newspeak. That's your answer right there. I have still to see a single example of a (non-contrived) usage of Alien that's faster than the equivalent (non-contrived) FFI call.
Point taken. Yes, you have to be a lot more clever to optimize such calls for your use scenarios, which, as you said, makes writing an application a lot more tedious process. But it is the price we pay, when need something to be heavily optimized, isnt?
Cheers, - Andreas