A suggestion ...

> Now -- there are critical things - and this is not on of them, just took
> me a bit of time
> to figure it out and patched it ...
>
> If you do right-click doit on VW and you are logged into Gemstone, it
> turns on
> forwarder and stub tracing.  We do lots of little scripts and this slows
> them down
> considerably.
>
> How about a new "doit" on right-click
>     trace it
> ???

> Dennis Smith wrote:
>> Now -- there are critical things - and this is not on of them, just
>> took me a bit of time
>> to figure it out and patched it ...
>>
>> If you do right-click doit on VW and you are logged into Gemstone, it
>> turns on
>> forwarder and stub tracing.  We do lots of little scripts and this
>> slows them down
>> considerably.
>>
>> How about a new "doit" on right-click
>>     trace it
>> ???
>
> Hi Dennis,
>
> I'm afraid I don't fully understand. It's true that we do turn on
> forwarderDebugging and stubDebugging during GUI doits, and turn them
> off afterwards. I'm not sure we *need* to do that, but don't see how
> that would slow your scripts down.
>
> I tried running a simple doit (3 + 4) in a workspace 10,000 times both
> with and without our debugging code. There wasn't much difference, in
> fact the run with our debugging code ran almost 10% faster (but that
> could be within the measurement error).
>
> Regards,
>
> -Martin
>

> Dennis Smith wrote:
>> Maybe its just the "feel" of so much being dumped to the transcript,
>> but if sure "feels" slower.
>> It also masks other things that WE put to the transcript.
>
> Thanks, I see your problem now. Yes, the debugging does log forwarder
> and stub operations to the transcript, and I can see how that would
> slow things down if you do a lot of it.
>
> I'll file a bug on that, it shouldn't be necessary to turn on
> debugging during all doits. Turning on debugging does avoid another
> fairly tricky problem, but we should be able to find another way
> around that.

> On 03/03/2010 9:53 PM, Martin McClure wrote:
>> Dennis Smith wrote:
>>> Maybe its just the "feel" of so much being dumped to the transcript,
>>> but if sure "feels" slower.
>>> It also masks other things that WE put to the transcript.
>>
>> Thanks, I see your problem now. Yes, the debugging does log forwarder
>> and stub operations to the transcript, and I can see how that would
>> slow things down if you do a lot of it.
>>
>> I'll file a bug on that, it shouldn't be necessary to turn on
>> debugging during all doits. Turning on debugging does avoid another
>> fairly tricky problem, but we should be able to find another way
>> around that.
> That sounds intriguing -- what kind of problem could 'debugging' deal
> with??  should I be concerned??

> Dennis Smith wrote:
>> On 03/03/2010 9:53 PM, Martin McClure wrote:
>>> Dennis Smith wrote:
>>>> Maybe its just the "feel" of so much being dumped to the
>>>> transcript, but if sure "feels" slower.
>>>> It also masks other things that WE put to the transcript.
>>>
>>> Thanks, I see your problem now. Yes, the debugging does log
>>> forwarder and stub operations to the transcript, and I can see how
>>> that would slow things down if you do a lot of it.
>>>
>>> I'll file a bug on that, it shouldn't be necessary to turn on
>>> debugging during all doits. Turning on debugging does avoid another
>>> fairly tricky problem, but we should be able to find another way
>>> around that.
>> That sounds intriguing -- what kind of problem could 'debugging' deal
>> with??  should I be concerned??
>
> It's tricky (for us), but not serious, so you probably need not be
> concerned. The bug that you have probably reintroduced with your
> override is that if you have an inspector on a stub or forwarder, and
> you do a doIt in that inspector that contains "self", "self" will
> refer to the delegate, not the stub or forwarder.
>
> Regards,
>
> -Martin
>