A few proposed is: additions

Juan,

Do you see an issue with is: overrides for fundamental things like #Boolean, #String, #Character, #Number and #Collection?  I'll be happy to submit the changes, I just wanted to see if you have a problem with the proposed changes first.

Thanks,
Phil


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Phil,

At first, when I coded the #is: methods I thought about using them
everywhere. But when the sender is really concerned about performance,
#is: might be too slow. The old #isXX with a hardcoded answer is faster.
You can check a bit the senders for #isBoolean, #isString, #isCharacter,
etc. So, I don't have anything about implementing it in the classes you
say, but please add a comment in the implementation in Object and in
those subclasses where the older #isXX is still there, to explain the
reason for having both.

BTW, several times somebody asked some good question like this one, that
I knew the answer, but hadn't thought about a clarifying comment. This
is the moment to add it!

Cheers,
Juan Vuletich

Phil (list) wrote:
> Juan,
>
> Do you see an issue with is: overrides for fundamental things like #Boolean, #String, #Character, #Number and #Collection?  I'll be happy to submit the changes, I just wanted to see if you have a problem with the proposed changes first.
>
> Thanks,
> Phil
>
>  


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan,

On Jun 8, 2012, at 7:41 AM, Juan Vuletich wrote:

> Hi Phil,
>
> At first, when I coded the #is: methods I thought about using them everywhere. But when the sender is really concerned about performance, #is: might be too slow. The old #isXX with a hardcoded answer is faster. You can check a bit the senders for #isBoolean, #isString, #isCharacter, etc. So, I don't have anything about implementing it in the classes you say, but please add a comment in the implementation in Object and in those subclasses where the older #isXX is still there, to explain the reason for having both.
>

Good point re: the performance concern.  I hadn't thought about that but will keep it in mind as it could potentially be an issue for something that might get called very frequently like is: #Character.  I wasn't clear if the plan was to completely do away with is* in favor of is: or not so your clarification helps.  So my followup question becomes: for something that is likely to be frequently called like #isCharacter that has previously been removed would you prefer to add it back in or replace it with is:?  Also, for cases where is: does make sense, have you considered rather than hard coding them, backing them up with a collection so that something along the lines of Smalltalk allProtocols could be implemented or is that also a performance concern?

> BTW, several times somebody asked some good question like this one, that I knew the answer, but hadn't thought about a clarifying comment. This is the moment to add it!
>
> Cheers,
> Juan Vuletich
>

That's part of why I'm asking some of these questions rather than just assuming/doing.  I figure since we now have the mailing list, let's take advantage of it to help document why things are the way they are as it will hopefully help us work in a coordinated manner.  Plus, I'm really lazy and would prefer not to make a bunch of changes that don't make sense :-)

Thanks,
Phil
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Phil,

Phil (list) wrote:
It just depends on what you need. What do you need it for? (if you don't
then just don't add it).

> Also, for cases where is: does make sense, have you considered rather than hard coding them, backing them up with a collection so that something along the lines of Smalltalk allProtocols could be implemented or is that also a performance concern?
>  

I never thought about that. Do you have an use case in mind? (I usually
avoid implementing stuff until I have a good reason. Having a use case
usually helps doing a better implementation).

You'd see how much of the code I write, I end discarding. Not a bad
thing to me!

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan,

On Jun 12, 2012, at 7:30 AM, Juan Vuletich wrote:

>> Good point re: the performance concern.  I hadn't thought about that but will keep it in mind as it could potentially be an issue for something that might get called very frequently like is: #Character.  I wasn't clear if the plan was to completely do away with is* in favor of is: or not so your clarification helps.  So my followup question becomes: for something that is likely to be frequently called like #isCharacter that has previously been removed would you prefer to add it back in or replace it with is:?  
>
> It just depends on what you need. What do you need it for? (if you don't then just don't add it).

Several of the packages I've ported used the old is* methods for type checking which I've either had to remove or replace with brittle class checks for now.  In addition, much of the code I'm writing would benefit from them as well.  There are two main situations that come to mind: the first being in-image behavior checking/documentation where type doesn't matter and the second is crossing the image boundary (FFI, emitting text/data files of a specific spec, etc.) where type is everything.  In both scenarios,  the intention is to have errors occur closer to the true source of the problem or ideally preventing the problem from occurring in the first place by noticing that a setter is performing an inbound check.  The second case being more useful when working with code written by someone else.

For example, some of the text/data processing I'm doing will result in the debugger effectively popping up in the middle of nowhere from a code standpoint because it really needed some kind of a date but was passed a string (or some other object behavior mismatch) at some point well before the code actually failed rather than when it finally needed that date behavior.  Iterating over a number is another fun scenario... tracing back to how that number got there isn't always easy as it may have been 25 steps ago in the 10th data file read etc.  Sometimes this is the result of bad data, sometimes it's me simply forgetting to parse/convert good data.

>
>> Also, for cases where is: does make sense, have you considered rather than hard coding them, backing them up with a collection so that something along the lines of Smalltalk allProtocols could be implemented or is that also a performance concern?
>>  
>
> I never thought about that. Do you have an use case in mind? (I usually avoid implementing stuff until I have a good reason. Having a use case usually helps doing a better implementation).
>

I have two in mind:

1) When thinking about overriding is:, it would be useful to be able to look at the other protocols defined to remain consistent where it makes sense (both in terms of defining a new protocol or re-using one that already exists).  Currently you'd have to browse all implementers of is: to do so.  Not a big deal when the number of is: overrides is small, but it becomes unwieldy fast.

2) When code breaks and you land in the debugger, it would be nice to have a quick way to answer the question 'what is this object it's having a problem with?' in a more abstract sense than what is its class.  Same issue re: browsing implementers of is: as there may be more than one override in the class hierarchy (i.e. if #Number were defined at the top of the hierarchy and #Float were defined further down in the case of numbers.).  This, matched with appropriate is: checks would make troubleshooting some problems much simpler.  Obviously, more classes need to override is: before this use case could be realized.

I guess how I'd envisioned it working is: would just become the test method and would call a class side protocols method that would actually return the collection of protocols that a given class supports.  Then in the debugger/workspace you'd call foo class protocols.

If there's a better way to accomplish either what I'm looking for in my first answer or what I'm proposing here I'm open to it, this is just what I've come up with (likely without considering other valid scenarios or issues).


True for me as well.

Thanks,
Phil
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

The E-Prime crowd is cringing and turning in their graves;)

Okay, so I kind of like #is: too, but I don't think we need it in the core.

Phil, if I understand you correctly, you want to a) use #is: and b) port packages that depend on #is:

Great! Me too.

Here's a crazy idea: (can anyone guess where I'm going with this?) why not create an external package that implements #is: and maintain it?

It wouldn't be a lot of work to do (at least I don't think so) and it would be a model external package for Cuis: small, simple, elegant, providing aspects of compatibility AND useful functionality to be pulled in by interested third parties (like me!) who like using #is: once in awhile in other external packages.

What do you think, Phil? Folks? I think it'd be really great as an example of how to make a simple external package for beginners.

My two cents:)


All the love, people of Cuis!

Casey

On Jun 12, 2012, at 12:48 PM, "Phil (list)" <[hidden email]> wrote:

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Phil,

Phil (list) wrote:
Oh, I hadn't thought about this. Apologies. I think that it makes a lot
of sense to add those is* methods in an optional package for
compatibility. When adapting a package for Cuis, if all the problems are
like this, it is easier to load the compatibility package and do not
fork the package you're working on. That would save a lot of code
duplication. Something else that could go in that compatibility package
is a SmalltalkImage class, whose single class message #current just
answers Smalltalk. Same for SystemNavigation current, and any other such
idioms that are absent in Cuis.

>  In addition, much of the code I'm writing would benefit from them as well.  There are two main situations that come to mind: the first being in-image behavior checking/documentation where type doesn't matter and the second is crossing the image boundary (FFI, emitting text/data files of a specific spec, etc.) where type is everything.  In both scenarios,  the intention is to have errors occur closer to the true source of the problem or ideally preventing the problem from occurring in the first place by noticing that a setter is performing an inbound check.  The second case being more useful when working with code written by someone else.
>
> For example, some of the text/data processing I'm doing will result in the debugger effectively popping up in the middle of nowhere from a code standpoint because it really needed some kind of a date but was passed a string (or some other object behavior mismatch) at some point well before the code actually failed rather than when it finally needed that date behavior.  Iterating over a number is another fun scenario... tracing back to how that number got there isn't always easy as it may have been 25 steps ago in the 10th data file read etc.  Sometimes this is the result of bad data, sometimes it's me simply forgetting to parse/convert good data.
>  

I see. In any case keep in mind that #is* and #is: are not type
checking, but more something like protocol conformance... In any case
they don't give any guarantees at all. Anybody could implement them in
any way...

The problem is that to access the whole collection, including those from
superclasses, you need to create collections on each call. This is too
expensive.

> If there's a better way to accomplish either what I'm looking for in my first answer or what I'm proposing here I'm open to it, this is just what I've come up with (likely without considering other valid scenarios or issues).
>
> ...

Let's think of a better one, one that is fast and non- redundant.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Casey,

Casey Ransberger wrote:
> The E-Prime crowd is cringing and turning in their graves;)
>
> Okay, so I kind of like #is: too, but I don't think we need it in the core.
>
> Phil, if I understand you correctly, you want to a) use #is: and b) port packages that depend on #is:
>  

Well, #is: is specific for Cuis. Other Squeak derivatives use #is*. As I
just said in another email, I think that 'missing' #is* method could go
in a compatibility package, with SmalltalkImage, SystemNavigation, and
other such foreign idioms.

> Great! Me too.
>
> Here's a crazy idea: (can anyone guess where I'm going with this?) why not create an external package that implements #is: and maintain it?
>
> It wouldn't be a lot of work to do (at least I don't think so) and it would be a model external package for Cuis: small, simple, elegant, providing aspects of compatibility AND useful functionality to be pulled in by interested third parties (like me!) who like using #is: once in awhile in other external packages.
>
> What do you think, Phil? Folks? I think it'd be really great as an example of how to make a simple external package for beginners.
>  

I agree, if you mean #is* and not #is:, as #is: is used by Cuis
itself... Please clarify.

> My two cents:)
>
>
> All the love, people of Cuis!
>
> Casey
>  

Thanks, Casey.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan,

On Jun 13, 2012, at 12:28 PM, Juan Vuletich wrote:

No reason you should have since compatibility isn't your primary concern (keep things small and dealing with breakage like this from time to time isn't a big deal for me :-)  I think the compatibility package sounds reasonable, so the only question becomes should it become part of something that already exists (i.e. the pharo-compat package or an equivalent squeak-compat (seems like the potential for conflict here would be high since pharo and squeak have their own issues re: compat)) or a stand alone thing.  Agreed re: not wanting to fork the package itself over trivial stuff like this (though for some packages it's necessary as they depend on too much cruft for my taste)

>
>> In addition, much of the code I'm writing would benefit from them as well.  There are two main situations that come to mind: the first being in-image behavior checking/documentation where type doesn't matter and the second is crossing the image boundary (FFI, emitting text/data files of a specific spec, etc.) where type is everything.  In both scenarios,  the intention is to have errors occur closer to the true source of the problem or ideally preventing the problem from occurring in the first place by noticing that a setter is performing an inbound check.  The second case being more useful when working with code written by someone else.
>>
>> For example, some of the text/data processing I'm doing will result in the debugger effectively popping up in the middle of nowhere from a code standpoint because it really needed some kind of a date but was passed a string (or some other object behavior mismatch) at some point well before the code actually failed rather than when it finally needed that date behavior.  Iterating over a number is another fun scenario... tracing back to how that number got there isn't always easy as it may have been 25 steps ago in the 10th data file read etc.  Sometimes this is the result of bad data, sometimes it's me simply forgetting to parse/convert good data.
>>  
>
> I see. In any case keep in mind that #is* and #is: are not type checking, but more something like protocol conformance... In any case they don't give any guarantees at all. Anybody could implement them in any way...

Understood, and I know there are no promises involved.

Sorry I wasn't explicit: I was assuming that there would be a cvar that got lazy loaded (including the walk up the hierarchy) by #protocols on the first call. From the second call on, the performance difference would just be a check for membership in the collection vs. the existing conditional logic approach.  A further assumption was that the class initialization logic would set the cvar to nil to ensure that there was a way to force its regeneration.

If you don't like the idea of creating per-override cvars, a centralized protocol dictionary (i.e. for classes with #is: overrides, the lookup would be performed and if it doesn't exist, populate it with what was returned from #protocols.) could be used instead.

A third approach could be to leave #is: alone and keep the introspection capabilities separate from the test, but then protocol information exists in at least two places: in the current #is: logic as well as the collection-backed store (whether via individual #protocols or a centralized store)

I think a fair question to ask is: does anyone else see value in what I'm proposing or is this something only I want?

>
>> If there's a better way to accomplish either what I'm looking for in my first answer or what I'm proposing here I'm open to it, this is just what I've come up with (likely without considering other valid scenarios or issues).
>>
>> ...
>
> Let's think of a better one, one that is fast and non- redundant.
>

I definitely appreciate those desires and concur.

> Cheers,
> Juan Vuletich


Thanks,
Phil
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Casey,

On Jun 13, 2012, at 3:40 AM, Casey Ransberger wrote:

> The E-Prime crowd is cringing and turning in their graves;)

OK, you got my interest... do tell!  (I'm not familiar with E-Prime)

>
> Okay, so I kind of like #is: too, but I don't think we need it in the core.
>
> Phil, if I understand you correctly, you want to a) use #is: and b) port packages that depend on #is:
>
> Great! Me too.
>

Assuming you meant a) #is: and b) #is*, yes

> Here's a crazy idea: (can anyone guess where I'm going with this?) why not create an external package that implements #is: and maintain it?
>
> It wouldn't be a lot of work to do (at least I don't think so) and it would be a model external package for Cuis: small, simple, elegant, providing aspects of compatibility AND useful functionality to be pulled in by interested third parties (like me!) who like using #is: once in awhile in other external packages.
>
> What do you think, Phil? Folks? I think it'd be really great as an example of how to make a simple external package for beginners.
>

As Juan said, if you meant #is*, I agree and my only question (in my previous message to Juan) is does it belong as part of a larger compatibility project or does it stand alone.

> My two cents:)
>
>
> All the love, people of Cuis!
>
> Casey
>

I definitely appreciate the discussion as I didn't want to go down the rabbit hole of implementing based on a bunch of my assumptions re: how this should work only to find out it only makes sense for me (without at least knowing that fact if it were the case).

Thanks,
Phil


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Well, heck. I think I may have misunderstood the entire conversation.

Sorry folks!

On Jun 13, 2012, at 9:34 AM, Juan Vuletich <[hidden email]> wrote:

> I agree, if you mean #is* and not #is:, as #is: is used by Cuis itself... Please clarify.

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Below.

On Jun 13, 2012, at 10:57 AM, "Phil (list)" <[hidden email]> wrote:

> Casey,
>
> On Jun 13, 2012, at 3:40 AM, Casey Ransberger wrote:
>
>> The E-Prime crowd is cringing and turning in their graves;)
>
> OK, you got my interest... do tell!  (I'm not familiar with E-Prime)

E-Prime is a maddeningly difficult variant of the English language which rejects all forms of the verbs meaning "to be."

This includes the word "is."

In E-Prime, the statement "To be or not to be, that is the question." is completely impossible. You end up with something like "To or not to, I perceive a question."

It's mostly useful in terms of enhancing one's point of view; the exercise of exorcizing is-ness forces one to look for some rather challenging ways of formulating arguments. It makes you think about things that we tend normally to take for granted.

Another thing that's fun to do (and not at all related to E-Prime) is to spend a week without using words that mean "I." I, me, mine.

Sorry to be off topic!

Casey
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Casey,

On Jun 14, 2012, at 5:28 AM, Casey Ransberger wrote:

> Well, heck. I think I may have misunderstood the entire conversation.
>
> Sorry folks!
>

That's my fault for not being clearer via selector syntax in the original post.  It's a bad habit that I'll continue to work on breaking.

Thanks,
Phil
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Phil,

I agree with what you say, so I snipped those parts (especially #is* in
compatibility package(s), that deserves a separate thread), to focus on
the implementation.

Phil (list) wrote:
Well, your first proposal here is indeed fast (especially if we use
#pointsTo:) and non-redundant. An issue is the need to call #initialize
when the collection changes. It would be nice if this was automatic,
somehow. Forgetting to do it could mean rather hard to find bugs. The
first thing that comes to my mind is to have a well known message that
gets sent to any class when a method is compiled. Let's see... (goes to
look in Cuis...) Hehehe. It is already there: #noteCompilationOf:meta: .
We can just use this method to clear the variable (btw, it shouldn't be
a classVar but a classInstVar, right?) if the protocols change.

Besides, it looks a bit complex, but it seems to me that the value is
greater than the complexity, so I'd go for it. Mhh. We'd also do some
space analysis. I guess we'd be using just a couple of kb of RAM, so
it's not an issue, but we should measure anyway.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Casey,

Casey Ransberger wrote:
> E-Prime is a maddeningly difficult variant of the English language which rejects all forms of the verbs meaning "to be."
>  

Wow. Had to look at the Wikipedia article to get it.

> This includes the word "is."
>
> In E-Prime, the statement "To be or not to be, that is the question." is completely impossible. You end up with something like "To or not to, I perceive a question."
>  

It is great! I love it! It really seems like a great exercise in clear
thought.

> It's mostly useful in terms of enhancing one's point of view; the exercise of exorcizing is-ness forces one to look for some rather challenging ways of formulating arguments. It makes you think about things that we tend normally to take for granted.
>
> Another thing that's fun to do (and not at all related to E-Prime) is to spend a week without using words that mean "I." I, me, mine.
>
> Sorry to be off topic!
>
> Casey

Hehehe. There's a game here (Argentina), I don't know if popular in
other places, that kids play, for example, in long car trips. It is to
have a conversation, but one of the kids is forbidden from using the
words 'yes', 'no', 'black' and 'white'. The point is to see for how long
you can go without using them inadvertently.

E-Prime, and your 'avoid I' game sound like more interesting versions of
this game, because as you play, your thoughts get clearer (with
E-Prime); or you get less egocentric (with 'avoid I').

Thanks for sharing this, Casey!

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan,

On Jun 15, 2012, at 7:05 AM, Juan Vuletich wrote:

> Hi Phil,
>
> I agree with what you say, so I snipped those parts (especially #is* in compatibility package(s), that deserves a separate thread), to focus on the implementation.
>

That makes sense... I'll think a bit more about the #is* options and start a new thread for that.

So here I am spit-balling a general notion of how to do it and you get all specific about how to do it even better :-)  Of course you're right about class inst vars being the way to go.

> Besides, it looks a bit complex, but it seems to me that the value is greater than the complexity, so I'd go for it. Mhh. We'd also do some space analysis. I guess we'd be using just a couple of kb of RAM, so it's not an issue, but we should measure anyway.
>

Since you've more than pointed me in the right direction, I went ahead and put together a test project to try to answer the memory and performance questions at https://github.com/pbella/Cuis-Experiments .  It implements parallel class hierarchies using the current #is: approach as well as one with the new approach we've been discussing.  Assuming my code is correct, performance varied from 4x faster (#is: checking multiple conditions) to 2.5x slower (simple #is: checks or the condition is matched quickly using the old method (i.e. without needing to walk the class hierarchy)) but you need a lot of iterations to even measure the difference on my machine at least.  Memory usage increased on the order of tens to a few hundred bytes per class (though I'm not sure how accurate the method I'm using is)  How does it look to you?

> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Thanks,
Phil
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Top post: a lot of iterations to see the difference? That's different. Still wondering if I'm still missing the point of this thread, but are you running on Cog or the interpreter?

On Jun 16, 2012, at 5:12 PM, "Phil (list)" <[hidden email]> wrote:

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Casey,

On Jun 18, 2012, at 3:33 AM, Casey Ransberger wrote:

> Top post: a lot of iterations to see the difference? That's different. Still wondering if I'm still missing the point of this thread, but are you running on Cog or the interpreter?

I'm running Cog on an i7-2600.  On that configuration, the fastest test completes in 0.07 seconds and the slowest in 0.7 seconds.  I just ran the same tests under the classic VM and the fastest test completes in 0.7 seconds and the slowest in 3 seconds (the relative performance of old vs. new changes to from 2x faster to 2x slower).  What results are you seeing on your machine? (if necessary, feel free to lower the iterations in LetsGetDownToIssness #timing from 5,000,000)

Thanks,
Phil
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Sadly, don't have my machine with me. On Cog, run it two or three times before benching. I can't recall if it's the second or third run that does the trick (I think it's the second,) but Cog doesn't actually start putting JIT'd methods into the poly whosit whatchamacallit cache (PIC) on the first run. It's sort of a stopgap until the work is done to make it smarter about inlining machine code, IIRC.

The fact that your slowest run was took the same amount of time on the interpreter suggests to me that on your slowest run, the method implementation wasn't JIT'd or cached. Of course I'm a VM noob so don't take my word for it; CC Eliot so he has an opportunity to set me straight (which would be a very nice thing to do!) if I'm wrong here.

Casey



On Jun 18, 2012, at 8:33 AM, "Phil (list)" <[hidden email]> wrote:

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Casey,

On Jun 18, 2012, at 9:54 PM, Casey ransberger wrote:

> Sadly, don't have my machine with me. On Cog, run it two or three times before benching. I can't recall if it's the second or third run that does the trick (I think it's the second,) but Cog doesn't actually start putting JIT'd methods into the poly whosit whatchamacallit cache (PIC) on the first run. It's sort of a stopgap until the work is done to make it smarter about inlining machine code, IIRC.
>
> The fact that your slowest run was took the same amount of time on the interpreter suggests to me that on your slowest run, the method implementation wasn't JIT'd or cached. Of course I'm a VM noob so don't take my word for it; CC Eliot so he has an opportunity to set me straight (which would be a very nice thing to do!) if I'm wrong here.
>
> Casey
>

I can see how reading my posts without seeing the output of the timings could lead you to that conclusion... my response was going on the assumption that you had run the tests on the Squeak VM and were seeing dramatically different (i.e. bad) results, so I followed up with my results on the Squeak VM which probably just muddied the waters.  Cog was quite consistent and was 3x-10x faster than the Squeak VM (it varied by test which is expected).  But there were no surprises comparing one VM vs. the other: Cog is *significantly* faster across the board, so I'm quite happy with Cog's performance :-)  When I ran the same tests on the different VM's, only the absolute performance changed as the relative performance re: old vs. new approach was similar.

To help you see what I'm talking about re: timings, here's the output from a complete run on Cog (the % represents the new vs. old durations which are displayed on the same line).  Each time is the result of 5,000,000 iterations of the test (i.e. they're both pretty fast) comparing old vs. new timings:

Timing tests
=========
ObjectMultiOldIs vs. ObjectMultiNewIs
26% is - ObjectMultiOldIs: 0:00:00:00.664, ObjectMultiNewIs: 0:00:00:00.174
26% isNess - ObjectMultiOldIs: 0:00:00:00.678, ObjectMultiNewIs: 0:00:00:00.182
31% isNess1 - ObjectMultiOldIs: 0:00:00:00.578, ObjectMultiNewIs: 0:00:00:00.18
29% isNess2 - ObjectMultiOldIs: 0:00:00:00.602, ObjectMultiNewIs: 0:00:00:00.178
26% isNess3 - ObjectMultiOldIs: 0:00:00:00.632, ObjectMultiNewIs: 0:00:00:00.17
27% isNessSub - ObjectMultiOldIs: 0:00:00:00.676, ObjectMultiNewIs: 0:00:00:00.184
27% noWay - ObjectMultiOldIs: 0:00:00:00.676, ObjectMultiNewIs: 0:00:00:00.184

ObjectMultiSubOldIs vs. ObjectMultiSubNewIs
25% is - ObjectMultiSubOldIs: 0:00:00:00.696, ObjectMultiSubNewIs: 0:00:00:00.176
26% isNess - ObjectMultiSubOldIs: 0:00:00:00.698, ObjectMultiSubNewIs: 0:00:00:00.184
29% isNess1 - ObjectMultiSubOldIs: 0:00:00:00.616, ObjectMultiSubNewIs: 0:00:00:00.184
28% isNess2 - ObjectMultiSubOldIs: 0:00:00:00.622, ObjectMultiSubNewIs: 0:00:00:00.176
26% isNess3 - ObjectMultiSubOldIs: 0:00:00:00.65, ObjectMultiSubNewIs: 0:00:00:00.172
238% isNessSub - ObjectMultiSubOldIs: 0:00:00:00.072, ObjectMultiSubNewIs: 0:00:00:00.172
26% noWay - ObjectMultiSubOldIs: 0:00:00:00.696, ObjectMultiSubNewIs: 0:00:00:00.184

ObjectNoneOldIs vs. ObjectNoneNewIs
237% is - ObjectNoneOldIs: 0:00:00:00.074, ObjectNoneNewIs: 0:00:00:00.176
242% isNess - ObjectNoneOldIs: 0:00:00:00.076, ObjectNoneNewIs: 0:00:00:00.184
244% isNess1 - ObjectNoneOldIs: 0:00:00:00.076, ObjectNoneNewIs: 0:00:00:00.186
251% isNess2 - ObjectNoneOldIs: 0:00:00:00.074, ObjectNoneNewIs: 0:00:00:00.186
244% isNess3 - ObjectNoneOldIs: 0:00:00:00.076, ObjectNoneNewIs: 0:00:00:00.186
247% isNessSub - ObjectNoneOldIs: 0:00:00:00.076, ObjectNoneNewIs: 0:00:00:00.188
244% noWay - ObjectNoneOldIs: 0:00:00:00.076, ObjectNoneNewIs: 0:00:00:00.186

ObjectRootOldIs vs. ObjectRootNewIs
247% is - ObjectRootOldIs: 0:00:00:00.072, ObjectRootNewIs: 0:00:00:00.178
254% isNess - ObjectRootOldIs: 0:00:00:00.074, ObjectRootNewIs: 0:00:00:00.188
247% isNess1 - ObjectRootOldIs: 0:00:00:00.076, ObjectRootNewIs: 0:00:00:00.188
247% isNess2 - ObjectRootOldIs: 0:00:00:00.076, ObjectRootNewIs: 0:00:00:00.188
254% isNess3 - ObjectRootOldIs: 0:00:00:00.074, ObjectRootNewIs: 0:00:00:00.188
235% isNessSub - ObjectRootOldIs: 0:00:00:00.08, ObjectRootNewIs: 0:00:00:00.188
247% noWay - ObjectRootOldIs: 0:00:00:00.076, ObjectRootNewIs: 0:00:00:00.188

ObjectSingleOldIs vs. ObjectSingleNewIs
204% is - ObjectSingleOldIs: 0:00:00:00.088, ObjectSingleNewIs: 0:00:00:00.18
244% isNess - ObjectSingleOldIs: 0:00:00:00.072, ObjectSingleNewIs: 0:00:00:00.176
208% isNess1 - ObjectSingleOldIs: 0:00:00:00.09, ObjectSingleNewIs: 0:00:00:00.188
211% isNess2 - ObjectSingleOldIs: 0:00:00:00.09, ObjectSingleNewIs: 0:00:00:00.19
208% isNess3 - ObjectSingleOldIs: 0:00:00:00.09, ObjectSingleNewIs: 0:00:00:00.188
204% isNessSub - ObjectSingleOldIs: 0:00:00:00.092, ObjectSingleNewIs: 0:00:00:00.188
208% noWay - ObjectSingleOldIs: 0:00:00:00.09, ObjectSingleNewIs: 0:00:00:00.188

Memory used
==========
111% ObjectMultiOldIs: 92, ObjectMultiNewIs: 103
142% ObjectMultiSubOldIs: 61, ObjectMultiSubNewIs: 87
0% ObjectNoneOldIs: 0, ObjectNoneNewIs: 0
549% ObjectRootOldIs: 61, ObjectRootNewIs: 335
134% ObjectSingleOldIs: 61, ObjectSingleNewIs: 82

Thanks,
Phil
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org