[Glass] Awfully slow GRUtf8CodecStream

Mariano,

It looks like you've hit a known problem[1] and I just  haven't gotten around to installing the bugfix in Grease...

There is a useful discussion about this in the Seaside31 issue #21[2] and for 3.2.2 we added a primitive, but I have yet to add the primitive call to the Grease base[3].

The patches are in Smalltalk, so if you'd apply the patches and let me know if they address your issue or not that'd be great.

I'm in the final throes of fixing a whole a pile of Metacello bugs[4], but I should be able to get around to the Grease patch in a couple of days if you want to wait ...

Dale

[1] https://github.com/GsDevKit/Grease/issues/2
[2] https://github.com/GsDevKit/Seaside31/issues/21
[3] https://github.com/glassdb/glass/issues/27
[4] https://github.com/dalehenrich/metacello-work/milestones/1.0.0-beta.32.16

On Wed, Oct 15, 2014 at 9:39 AM, Mariano Martinez Peck via Glass <[hidden email]> wrote:

Hi guys,

I am rendering a html table of 100rows and 20 columns using Seaside. In Pharo, the "render" request of Seaside takes approx. 200ms. In Gemstone, same request takes more than 2 seconds....

I have run a profiler and it looks the very very slow part is the #nextPutAll: of GRUtf8CodecStream, And more precisely, the Utf8 >> asString that ends up calling #changeClassTo:, which is the guy taking most of the time (60%!!!!!).

Using a GRNullCodec decreases at least to 1 second. It is still far from the 200ms from Pharo, but it is better. GRLatin1GemStoneCodec does not even work. 

Another reason of the slowness in gemstone is that I don't have native code enabled in the seaside gems. I would like to do so, but then I cannot remote debug anymore. 

I am using Gemstone 3.1.0.6 and Seaside 3.1.3. 

Is there any workaround or hack I can do to improve performance a bit?

thanks, 

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Wed, Oct 15, 2014 at 3:27 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

It looks like you've hit a known problem[1] and I just  haven't gotten around to installing the bugfix in Grease...

Thanks Dale, I wasn't aware. 

 

There is a useful discussion about this in the Seaside31 issue #21[2] and for 3.2.2 we added a primitive, but I have yet to add the primitive call to the Grease base[3].

If by chance there is a future 3.1.0.7 is there a chance to have such primitive integrated? 

 

The patches are in Smalltalk, so if you'd apply the patches and let me know if they address your issue or not that'd be great.

I have just tried: https://github.com/GsDevKit/Grease/issues/2

Wow....I have just tried that, and in my case, it produced a performance improvement of 4x. My table rendering decreased from 4s to 1s approx. 

Then I tried adding some none ascii characters like:

An preost wes on leoden, Laȝamon was ihoten

He wes Leovenaðes sone -- liðe him be Drihten.

He wonede at Ernleȝe at æðelen are chirechen,

Uppen Sevarne staþe, sel þar him þuhte,

Onfest Radestone, þer he bock radde.

and they were correctly displayed. So I guess it is working correctly (else I don't know what easy other stuff to test). 

On Wed, Oct 15, 2014 at 12:10 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Wed, Oct 15, 2014 at 3:27 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

It looks like you've hit a known problem[1] and I just  haven't gotten around to installing the bugfix in Grease...

Thanks Dale, I wasn't aware. 

 

There is a useful discussion about this in the Seaside31 issue #21[2] and for 3.2.2 we added a primitive, but I have yet to add the primitive call to the Grease base[3].

If by chance there is a future 3.1.0.7 is there a chance to have such primitive integrated? 

It's not likely that there will be a 3.1.0.7 and if it does get released it will likely be limited to fix a critical production problem.

 

The patches are in Smalltalk, so if you'd apply the patches and let me know if they address your issue or not that'd be great.

I have just tried: https://github.com/GsDevKit/Grease/issues/2

Wow....I have just tried that, and in my case, it produced a performance improvement of 4x. My table rendering decreased from 4s to 1s approx. 

Then I tried adding some none ascii characters like:

An preost wes on leoden, Laȝamon was ihoten

He wes Leovenaðes sone -- liðe him be Drihten.

He wonede at Ernleȝe at æðelen are chirechen,

Uppen Sevarne staþe, sel þar him þuhte,

Onfest Radestone, þer he bock radde.

and they were correctly displayed. So I guess it is working correctly (else I don't know what easy other stuff to test). 

I'm glad to see that you're getting an acceptable improvement ... I just have to make the time to integrate the fix ...

Another reason of the slowness in gemstone is that I don't have native code enabled in the seaside gems. I would like to do so, but then I cannot remote debug anymore. 

On Wed, Oct 15, 2014 at 9:39 AM, Mariano Martinez Peck via Glass <[hidden email]> wrote:

Another reason of the slowness in gemstone is that I don't have native code enabled in the seaside gems. I would like to do so, but then I cannot remote debug anymore. 

Mariano,

With the 3.1.0.6 and 3.2.2 (the two versions that I've tested with), you CAN do remote debugging without diabling native code ...

I know the  startSeaside30_Adaptor script has some code that doesn't enable the Breakpoint exception unless native code is enabled, but that is no longer correct (and it looks like I won't be able to fix that before 3.2.3 gets released either as the release is imminent)...

There are still some issues in 3.2.2 (and earlier) with proceeding from remote Breakpoints,

but the error handling and other facilities work quite fine with Native code enabled .. the vms have been updated so that native code is automatically disabled when a breakpoint is hit, but new processes will be created in native mode ...

On Wed, Oct 15, 2014 at 5:56 PM, Dale Henrichs <[hidden email]> wrote:

On Wed, Oct 15, 2014 at 9:39 AM, Mariano Martinez Peck via Glass <[hidden email]> wrote:

Another reason of the slowness in gemstone is that I don't have native code enabled in the seaside gems. I would like to do so, but then I cannot remote debug anymore. 

Mariano,

With the 3.1.0.6 and 3.2.2 (the two versions that I've tested with), you CAN do remote debugging without diabling native code ...

mmmmmmm if I understand this correct...then this is huge good news (in 3.1.0.5 I was never ever able to do that). 

 

I know the  startSeaside30_Adaptor script has some code that doesn't enable the Breakpoint exception unless native code is enabled, but that is no longer correct (and it looks like I won't be able to fix that before 3.2.3 gets released either as the release is imminent)...

OK. I use my own "form" of startSeaside30_Adaptor so I have no problem to change myself my script. The part you seem to refer is this?

GsProcess usingNativeCode not

  ifTrue: [

    "Enable remote Breakpoing handling"

    Breakpoint trappable: true.

    GemToGemAnnouncement installStaticHandler.

    System commitTransaction ifFalse: [ nil error: 'Could not commit for GemToGemSignaling' ].

  ].

If I understand you correct, what you say is that from 3.1.0.6 and beyond I should remove the "GsProcess usingNativeCode not"  IF ?

There are still some issues in 3.2.2 (and earlier) with proceeding from remote Breakpoints,

Ok, that is asking too much ;) I am ok with at least be able to debug and not be able to proceed :)

 

but the error handling and other facilities work quite fine with Native code enabled .. the vms have been updated so that native code is automatically disabled when a breakpoint is hit, but new processes will be created in native mode ...

mmmm do you recall when that was changed? I ask because I checked the release notes of 3.1.0.6 for this exact issue: http://downloads.gemtalksystems.com/docs/GemStone64/3.1.x/GS64-ReleaseNotes-3.1.0.6.pdf 

and I found no mention at all about this... and with 3.1.0.5 it never worked for me....so....the VM were updated even before 3.1.0.6 and the reason it didn't work for me was because of the above IF? or the changes to the VM were forgotten in 3.1.0.6 release notes?

Thanks for any clarification!

On Wed, Oct 15, 2014 at 2:23 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Wed, Oct 15, 2014 at 5:56 PM, Dale Henrichs <[hidden email]> wrote:

On Wed, Oct 15, 2014 at 9:39 AM, Mariano Martinez Peck via Glass <[hidden email]> wrote:

Another reason of the slowness in gemstone is that I don't have native code enabled in the seaside gems. I would like to do so, but then I cannot remote debug anymore. 

Mariano,

With the 3.1.0.6 and 3.2.2 (the two versions that I've tested with), you CAN do remote debugging without diabling native code ...

mmmmmmm if I understand this correct...then this is huge good news (in 3.1.0.5 I was never ever able to do that). 

 

I know the  startSeaside30_Adaptor script has some code that doesn't enable the Breakpoint exception unless native code is enabled, but that is no longer correct (and it looks like I won't be able to fix that before 3.2.3 gets released either as the release is imminent)...

OK. I use my own "form" of startSeaside30_Adaptor so I have no problem to change myself my script. The part you seem to refer is this?

GsProcess usingNativeCode not

  ifTrue: [

    "Enable remote Breakpoing handling"

    Breakpoint trappable: true.

    GemToGemAnnouncement installStaticHandler.

    System commitTransaction ifFalse: [ nil error: 'Could not commit for GemToGemSignaling' ].

  ].

If I understand you correct, what you say is that from 3.1.0.6 and beyond I should remove the "GsProcess usingNativeCode not"  IF ?

yes ... from 3.1.0.6 on (at least), you can enable the Breakpoint exception and use breakpoints for remote debugging...

There are still some issues in 3.2.2 (and earlier) with proceeding from remote Breakpoints,

Ok, that is asking too much ;) I am ok with at least be able to debug and not be able to proceed :)

When you say "remote debug" are you referring specifically to setting remote breakpoints?

 

but the error handling and other facilities work quite fine with Native code enabled .. the vms have been updated so that native code is automatically disabled when a breakpoint is hit, but new processes will be created in native mode ...

mmmm do you recall when that was changed? I ask because I checked the release notes of 3.1.0.6 for this exact issue: http://downloads.gemtalksystems.com/docs/GemStone64/3.1.x/GS64-ReleaseNotes-3.1.0.6.pdf 

and I found no mention at all about this... and with 3.1.0.5 it never worked for me....so....the VM were updated even before 3.1.0.6 and the reason it didn't work for me was because of the above IF? or the changes to the VM were forgotten in 3.1.0.6 release notes?

Thanks for any clarification!

there are two things at work here ... the version of Seaside and the capability within the vm ... I reviewed the release notes myself and did not see anything talking about native code changes related to debugging, so I'm not sure myself when breakpoints and native code got cleaned up (probably somewhere between 3.1.0.2 and 3.1.0.5 )... unfortunately we don't necessarily record all changes made to the system in release notes ...

The version of Seaside also plays a role ... Although I can't find anything in the commit logs, I seem to remember that I did some work this year to make sure that remote breakpoints were funcational and I recall that I did have to fix some bugs to get things rolling again, so the potential for remote breakoints may have been in 3.1.0.5, but the code wasn't present in Seaside (or perhaps GLASS) ...