Re: Re: TableReport slow down

This code should illustrate what is happening:

[ String streamContents: [ :out |
    out << 'Pricelist'; cr.
    1 to: 1000 do: [ :each |
      out << 'Item nr. ' << each << ' costs EUR' << (each * 100); cr ] ] ] bench. 

"'1,662 per second'"

[ String streamContents: [ :out |
    out << 'Pricelist'; cr.
    1 to: 1000 do: [ :each |
      out << 'Item nr. ' << each << ' costs €' << (each * 100); cr ] ] ] bench. 

"'710.058 per second'"

[ String streamContents: [ :out |
    out << 'Pricelist'; cr.
    1 to: 1000 do: [ :each |
      out << (String streamContents: [ :str | 
                str << 'Item nr. ' << each << ' costs €' << (each * 100); cr ]) ] ] ] bench. 
			
 "'156.350 per second'"

I suspect you are in the third case: by calling #printString for each item, you implicitly invoke the #become: (a factor 10 slowdown) - In the second case, this happens only once.

Johan's suggestion is an easy solution, but basically comes down to 'do not use anything outside Latin1 unless you HTML encode it', which is (1) quite limited (2) should not be your job.

Generating raw UTF-8 yourself is not a good idea I think (it goes against the way Strings are supposed to work).

I use the Euro sign and other Unicode characters in a Seaside web app without encoding them and I did not notice any slowdowns (http://store.audio359.eu).

> On 01 Jan 2016, at 22:13, Johan Brichau <[email protected]> wrote:
> 
> 
>> On 01 Jan 2016, at 16:51, Hilaire <[email protected]> wrote:
>> 
>> Posted there https://github.com/SeasideSt/Seaside/issues/862
>> For me it is all utf8, but it looks like not all along the way...
> 
> Thanks for posting that.
> Since the slowdown is only in the example where you concatenate the euro symbol to the string before writing it on the canvas, it’s definitely not something we can/should solve in Seaside.
> I wanted to make sure if there is anything that slows down the page rendering when there are widestrings being put on the canvas, but it’s clearly not the case.
> 
> I think the only solution is to separate the rendering of the object on a Seaside canvas and the Pharo object inspector.
> I.e. write a #renderOn: html method on the object which implemented the optimal way of rendering it on a Seaside canvas.
> 
> cheers,
> Johan_______________________________________________
> seaside mailing list
> [email protected]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside