On 25 March 2010 18:35, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 3/25/2010 9:04 AM, Igor Stasenko wrote:
>>>
>>>        drawable := OpenGLSurface newIn: (0 at 0 corner: 10 at 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
>
>



-- 
Best regards,
Igor Stasenko AKA sig.