TableReport slow down
Locked
 
|
Hello,
I am experiencing a slow down rendering a large table report: The table report is more than 240 lines. Reading at the source html, it is about 900 bytes per lines, so a bit more than 200kB for the report. Not much for the rest of the page. The page renders in a bit more 5s, on a local loop. Profiling shows most of time is spent in WideString>>at:put: For me 200KB is not that big and this slow down does not look normal. Seaisde is 3.1.3.2 Smalltalk is Pharo3 CPU is double core intel 800Mhz-2000Mhz VM is 3.9-7 The profiling tree is as shown in the screenshot. Thanks Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Tree.png (39K) |
|
Hello,
Some investigation shows an issue while appending an € symbol in the text representation of my money object (the one used by seaside for rendering) CGMoney>>printOn: aStream aStream << (amount asScaledDecimal: 2) greaseString << ' ' << '€' Replacing '€' by 'EUR' gives back normal rendering time. Indeed the '€' is encoded as WideString, so not sure what is happening. All content converted to WideString or what? But I really want to rendery euro symbol Thanks Hilaire Le 31/12/2015 14:32, Hilaire a écrit : Hello, I am experiencing a slow down rendering a large table report: The table report is more than 240 lines. Reading at the source html, it is about 900 bytes per lines, so a bit more than 200kB for the report. Not much for the rest of the page. The page renders in a bit more 5s, on a local loop. Profiling shows most of time is spent in WideString>>at:put: For me 200KB is not that big and this slow down does not look normal. Seaisde is 3.1.3.2 Smalltalk is Pharo3 CPU is double core intel 800Mhz-2000Mhz VM is 3.9-7 The profiling tree is as shown in the screenshot. Thanks Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: TableReport slow down
|
> On 31 Dec 2015, at 15:02, Hilaire <[hidden email]> wrote: > > Hello, > > Some investigation shows an issue while appending an € symbol in the text representation of my money object (the one used by seaside for rendering) > > CGMoney>>printOn: aStream > aStream << (amount asScaledDecimal: 2) greaseString << ' ' << '€' > > Replacing '€' by 'EUR' gives back normal rendering time. > > Indeed the '€' is encoded as WideString, so not sure what is happening. All content converted to WideString or what? Yes, the string starts as a plain ByteString and once you add the € it gets automagically converted to a WideString, but you pay a huge price in performance: it involves the usage of global #become: each time, which is dead slow (Spur will help IIUC). A possible solution is to somehow start with a WideString from the beginning (or force it before doing all elements one by one). > But I really want to rendery euro symbol > > Thanks > > Hilaire > > > Le 31/12/2015 14:32, Hilaire a écrit : >> Hello, >> >> I am experiencing a slow down rendering a large table report: >> >> The table report is more than 240 lines. Reading at the source html, it >> is about 900 bytes per lines, so a bit more than 200kB for the report. >> Not much for the rest of the page. The page renders in a bit more 5s, on >> a local loop. >> Profiling shows most of time is spent in WideString>>at:put: >> >> For me 200KB is not that big and this slow down does not look normal. >> >> Seaisde is 3.1.3.2 >> Smalltalk is Pharo3 >> CPU is double core intel 800Mhz-2000Mhz >> VM is 3.9-7 >> >> The profiling tree is as shown in the screenshot. >> >> Thanks >> >> Hilaire >> >> >> >> >> _______________________________________________ >> seaside mailing list >> >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > -- > Dr. Geo > > http://drgeo.eu > http://google.com/+DrgeoEu > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Le 31/12/2015 15:42, Sven Van Caekenberghe a écrit :
> A possible solution is to somehow start with a WideString from the beginning (or force it before doing all elements one by one). In the hack you are suggesting, does it not required the whole contents of the rendered page html code to be put as WideString? Indeed, hacking only my object #printOn: method to send WideString to the stream does not help. Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
What worked for me once upon a time was to
convert the euro character to a series of utf-8 bytes.
http://www.fileformat.info/info/unicode/char/20aC/index.htm so, for euro-currency sign U+20A0 you would need a 3-byte string whose characters in hex were: 0xE2 0x82 0xAC In squeak, I used this utf8ForCodePoint: cp "=== SEUtils utf8ForCodePoint: 16r2190 16r2190 radix: 2 '10000110010000' 16 U+FFFF 1110xxxx 10xxxxxx 10xxxxxx ===" | bits answer | bits := (cp radix: 2) padded: #left to: 16 with: $0. answer := String new. { '2r1110',(bits copyFrom: 1 to: 4). '2r10',(bits copyFrom: 5 to: 10). '2r10',(bits copyFrom: 11 to: 16). } do: [ :radix2 | answer := answer, (String with: (Character value: radix2 asNumber)). ]. ^answer On 1/1/16 5:09 AM, Hilaire wrote: Le 31/12/2015 15:42, Sven Van Caekenberghe a écrit :A possible solution is to somehow start with a WideString from the beginning (or force it before doing all elements one by one).In the hack you are suggesting, does it not required the whole contents of the rendered page html code to be put as WideString? Indeed, hacking only my object #printOn: method to send WideString to the stream does not help. Hilaire _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by HilaireFernandes
Hi Hilaire,
If you are rendering a euro symbol on an html page, it’s probably better to use the html character code: html encodeCharacter: Character euro -or- html html: '€’ It would also be helpful if you report the performance issue you have with some canonical code to reproduce it on https://github.com/SeasideSt/Seaside/issues It might be useful to investigate what happens and if it can be prevented. Though, the page document always needs to be encoded as a utf8 document, so I assume internally a bytestring is used. happy new year Johan
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Le 01/01/2016 13:00, Johan Brichau a écrit :
> Hi Hilaire, > > If you are rendering a euro symbol on an html page, it’s probably > better to use the html character code: > > html encodeCharacter: Character euro > -or- > html html: '€’ Yes, but I want to do it at the object level with its text representation. So I can have a nice view of this object from both the web browser and the Pharo environment. > > It would also be helpful if you report the performance issue you have > with some canonical code to reproduce it > on https://github.com/SeasideSt/Seaside/issuesIt might be useful to > investigate what happens and if it can be prevented. Though, the page > document always needs to be encoded as a utf8 document, so I assume > internally a bytestring is used. 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 Hilaire _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Bob Arning-2
Thanks for the tips. I naively try this: printOn: aStream << (amount asScaledDecimal: 2) greaseString << ' ' << (ByteArray with: 16rE2 with: 16r82 with: 16rAC) asString But somehow I must be missing something because it does not work as expected. I got garbage currency :) 514.25 ⬠Hilaire Le 01/01/2016 12:54, Bob Arning a écrit : What worked for me once upon a time was to convert the euro character to a series of utf-8 bytes. -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Sounds like an encoding issue. Your code
inserted into my app produced a euro sign where I had been
printing a fancy leftarrow. This is a much older seaside and has a
GRNullCodec as the codec of the requestContext. If you are using a
different codec, then it may be thinking your utf8 euro sign is
really 3 oddball characters and rendering them separately. Perhaps
you can do something with the codec (like use a null?).
On 1/1/16 11:19 AM, Hilaire wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Le 01/01/2016 18:16, Bob Arning a écrit :
> Sounds like an encoding issue. Your code inserted into my app produced > a euro sign where I had been printing a fancy leftarrow. This is a > much older seaside and has a GRNullCodec as the codec of the > requestContext. If you are using a different codec, then it may be > thinking your utf8 euro sign is really 3 oddball characters and > rendering them separately. Perhaps you can do something with the codec > (like use a null?). Understood the general idea but not sure how to proceed. Thanks for the tips anyway. Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by HilaireFernandes
> On 01 Jan 2016, at 16:51, Hilaire <[hidden email]> 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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
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 <[hidden email]> wrote: > > >> On 01 Jan 2016, at 16:51, Hilaire <[hidden email]> 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 > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
No, that’s not what I am suggesting and there is absolutely no issue when adding widestrings to the Seaside document when generating. That is what I wanted to make sure when I asked Hilaire to report the issue on github. As Hilaire points out himself (and your code snippets also demonstrate that), the issue is the string concatenation before you put the string on the Seaside document: Time millisecondsToRun: [WAHtmlCanvas builder render: [ :html | 1500 timesRepeat: [ html text: 'hello', '€' ] ]]. -> +- 3000ms on my machine Time millisecondsToRun: [WAHtmlCanvas builder render: [ :html | 1500 timesRepeat: [ html text: 'hello'; text: '€' ] ]]. -> +- 5ms on my machine My suggestion is not to use the #printOn: method for rendering the object on a Seaside canvas, but rather implement a #renderOn: method that avoids concatenating the String and WideString instances. cheers Johan _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Le 02/01/2016 09:45, Johan Brichau a
écrit :
Thanks for the tip it helps. However use of renderOn: will have some large implication on my Seaside components. Each use case of this object in component need to be rewritten to use only render:. I don't like much this idea, it makes the written code less elegant and consistent. Next, I understand now why I noticed this important slow down from the Pharo Inspector when browsing such collection object with € symbol on the EyeTreeInspector. I was first believing the slow down was because of the Inspector, but it is the same problem, which appear more clearly as a limitation of Pharo itself. I will resume discussion on the Pharo user list then. Thanks Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: TableReport slow down
|
|
In reply to this post by Johan Brichau-2
> On 02 Jan 2016, at 09:45, Johan Brichau <[hidden email]> wrote: > > >> On 02 Jan 2016, at 01:22, Sven Van Caekenberghe <[hidden email]> wrote: >> >> 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. > > No, that’s not what I am suggesting and there is absolutely no issue when adding widestrings to the Seaside document when generating. That is what I wanted to make sure when I asked Hilaire to report the issue on github. > As Hilaire points out himself (and your code snippets also demonstrate that), the issue is the string concatenation before you put the string on the Seaside document: > > Time millisecondsToRun: [WAHtmlCanvas builder render: [ :html | > 1500 timesRepeat: [ html text: 'hello', '€' ] ]]. > > -> +- 3000ms on my machine > > Time millisecondsToRun: [WAHtmlCanvas builder render: [ :html | > 1500 timesRepeat: [ html text: 'hello'; text: '€' ] ]]. > > -> +- 5ms on my machine > > My suggestion is not to use the #printOn: method for rendering the object on a Seaside canvas, but rather implement a #renderOn: method that avoids concatenating the String and WideString instances. That is an excellent summary of the issue, and a good solution indeed. > cheers > Johan > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by HilaireFernandes
Hilaire,
Am 02.01.16 um 10:12 schrieb Hilaire: since the behavior isn't consistent, I don't see why you should bother... And just to make sure we're not sending you in the wrong direction: Johan surely doesn't suggest turning your model objects into WAComponents. You don't have to use #render:, and maybe you shouldn't even call the method anything like #render, just use some method that accepts a renderer as parameter and renders html onto it. OTOH, speaking of the inspector: not sure about Pharo, but in VA there is #printOn: and #debugPrintOn:, so you could also choose to implement special behavior for inspecting/debugging purposes. This would probably not really solve the concatenation problem, so maybe not even a relevant note ;-) On a side note: I have decided to not use printOn: for application purposes if ever possible for similar reasons since I use Seaside. Too often I had to implement different representation logic for the application and myself as the developer. Having to go through a horribly long list of senders of #printString, #printOn: and sometimes even #asString in order to decide whether it's one or the other several times was an exercise that asks for avoidance... Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Le 02/01/2016 11:04, [hidden email] a écrit :
> And just to make sure we're not sending you in the wrong direction: > Johan surely doesn't suggest turning your model objects into > WAComponents. You don't have to use #render:, and maybe you shouldn't > even call the method anything like #render, just use some method that > accepts a renderer as parameter and renders html onto it. Hi Joachim If I understood correctly, 1. I need to implement my own*renderOn:* method for my object, (with code like: *html text: amount; text: ' '; text: '€' *) 2. then from any component I render this object with *html render: myObject.* This is what I tested and it provided normal expected rendering time. But it seems you mean something a bit different: no need to use #render: Am I missing something? Thanks Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |