Re: What is the purpose of static typing?
Re: What is the purpose of static typing?
- Subject: Re: What is the purpose of static typing?
- From: Philip George <email@hidden>
- Date: Thu, 25 Jul 2002 07:13:26 -0500
Okay, so I got rid of the threads and I setup two buttons. One button
draws the 'id' window and logs the start and end. The other does the
same but for the statically typed window. Here are the results (ALL of
the results) with the difference in creation/draw time under each set of
log statements:
(Note that there are 50 NSTextFields in each window. They're
statically-typed in the statically-typed win and id-typed in the id win.)
2002-07-25 06:28:38.182 windowrace[1702] id objects START
2002-07-25 06:28:38.896 windowrace[1702] id objects END
2002-07-25 06:28:41.055 windowrace[1702] statically-typed objects START
2002-07-25 06:28:41.355 windowrace[1702] statically-typed objects END
.414
2002-07-25 06:35:03.185 windowrace[1705] id objects START
2002-07-25 06:35:03.492 windowrace[1705] id objects END
2002-07-25 06:35:05.787 windowrace[1705] statically-typed objects START
2002-07-25 06:35:06.074 windowrace[1705] statically-typed objects END
.200
2002-07-25 06:36:17.366 windowrace[1706] id objects START
2002-07-25 06:36:17.674 windowrace[1706] id objects END
2002-07-25 06:36:18.909 windowrace[1706] statically-typed objects START
2002-07-25 06:36:19.202 windowrace[1706] statically-typed objects END
.150
2002-07-25 06:36:39.022 windowrace[1707] id objects START
2002-07-25 06:36:39.334 windowrace[1707] id objects END
2002-07-25 06:36:40.626 windowrace[1707] statically-typed objects START
2002-07-25 06:36:40.919 windowrace[1707] statically-typed objects END
.190
2002-07-25 06:37:07.634 windowrace[1708] id objects START
2002-07-25 06:37:07.938 windowrace[1708] id objects END
2002-07-25 06:37:09.747 windowrace[1708] statically-typed objects START
2002-07-25 06:37:10.032 windowrace[1708] statically-typed objects END
.190
2002-07-25 06:37:32.098 windowrace[1709] id objects START
2002-07-25 06:37:32.408 windowrace[1709] id objects END
2002-07-25 06:37:34.037 windowrace[1709] statically-typed objects START
2002-07-25 06:37:34.332 windowrace[1709] statically-typed objects END
.150
I realize this is a rather crude benchmark, but it still illustrates my
point: extra time is required to handle dynamically-typed objects at
runtime.
Note that the 'id' window didn't beat the statically-typed window even
once. They came close sometimes, but static typing always won.
Usually you wouldn't notice, because it might just be a couple little
objects, but I am talking about when you mass produce objects as id.
- Philip
On Thursday, July 25, 2002, at 02:53 AM, Ryan Dingman wrote:
>
*This message was transferred with a trial version of CommuniGate(tm)
>
Pro*
>
>
Hi Philip,
>
>
Richard is correct. You are very far from reality here. The _only_
>
time where dynamic versus static typing makes a difference is a compile
>
time. It makes _no_ difference at runtime. Static typing helps the
>
compiler check that the object in question actually responds to the
>
methods which are invoked on it. Your "benchmark" isn't demonstrating
>
what you think it is. Your use of threads is likely skewing the
>
results.
>
>
HTH,
>
>
ryan
>
>
On Wednesday, July 24, 2002, at 09:35 PM, Richard Wolf wrote:
>
>
> On Wednesday, July 24, 2002, at 09:27 PM, Philip George wrote:
>
>
>
>> They're bound "as needed" during runtime, not at applaunch, so as
>
>> users pop open new windows (for instance) they are bound at that
>
>> moment. Once bound, it's smooth sailing, but the user does have to
>
>> wait for binding to take place that very first time that object is
>
>> used/referenced.
>
>
>
> Okay, but if I'm reading Apple's Objective C bible correctly, methods
>
> are always bound to objects "as needed" regardless of whether you
>
> statically type them or not. If you statically type an object in
>
> source, it will -still- be bound to a message at runtime "as needed"
>
> and not initially ... when the app launches.
>
>
>
>> I just created a test app with two nswindows (programatically)
>
>> created and each has 50 nstextfields. win1 and it's 50 textfields
>
>> are all typed as "id" while WIN2 and it's 50 textfields are
>
>> statically typed.
>
>
>
> Okay ...
>
>
>
>> after app launch i click the button, whose action method detaches the
>
>> 2 threads like so:
>
>>
>
>> - (IBAction)myAction:(id)sender {
>
>> [NSThread detachNewThreadSelector:@selector(winONE:)
>
>> toTarget:self withObject:nil];
>
>> [NSThread detachNewThreadSelector:@selector(winTWO:)
>
>> toTarget:self withObject:nil];
>
>> }
>
>>
>
>> Notice that I give the 'id' window a head start. Even with the head
>
>> start, the 'id' window is drawn **long** after the statically typed
>
>> window and it's statically typed textfields are completely drawn to
>
>> the screen.
>
>
>
> I don't buy your methodology ... :-)
>
>
>
> Because you're using NSThreads, which are built on top of
>
> pthreads/Mach, you can't have any real idea how each thread is
>
> scheduled. I don't think it's safe to say, for example, that
>
> "winONE's" thread is given a "head start" just because you spawn it
>
> one line before "winTWO's" thread in your source. pthreads can
>
> schedule the threads any way it likes and you wouldn't know. :-)
>
> What's more, it can suspend execution of any thread at any time and
>
> there is no way for you to accurately predict or control when it does
>
> so.
>
>
>
> Not that I'm saying you're wrong ... but you'll have to come up with a
>
> better benchmark. If you are right, I'm going to re-read all the
>
> books I have and start seriously going after non-statically typed
>
> outlets. But my understanding, from all the newbie books, is that it
>
> doesn't matter from a runtime perspective whether you statically or
>
> dynamically type object pointers.
>
> _______________________________________________
>
> cocoa-dev mailing list | email@hidden
>
> Help/Unsubscribe/Archives:
>
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.