On Thu, Jan 17, 2013 at 12:15 PM, Cedric BAIL <cedric.b...@free.fr> wrote: > On Thu, Jan 17, 2013 at 10:34 PM, Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> wrote: >> On Thursday, January 17, 2013, Cedric BAIL wrote: >>> On Thu, Jan 17, 2013 at 9:37 PM, Gustavo Sverzut Barbieri >>> <barbi...@profusion.mobi <javascript:;>> wrote: >>> > On Thursday, January 17, 2013, Cedric BAIL wrote: >>> >> On Thu, Jan 17, 2013 at 7:28 PM, Gustavo Sverzut Barbieri >>> >> <barbi...@profusion.mobi <javascript:;> <javascript:;>> wrote: >>> >> > On Thursday, January 17, 2013, Enlightenment SVN wrote: >>> >> >> Log: >>> >> >> efl: stupid micro optimization. >>> >> >> >>> >> >> This single test accounted for 1% of my terminology benchmark. >>> >> >> I am considering moving evas_string_char_next_get and >>> >> >> eina_unicode_utf8_get_next to become inline as their function >>> >> >> entry/exit point account for 3% of the same benchmark. >>> >> >> >>> >> >> The biggest win would be to get rid of the memcpy >>> _termpty_text_copy >>> >> >> that account for 16%. >>> >> >> >>> >> >> In the micro optimization part, we also still do to much malloc >>> >> >> in font_draw_prepare as we don't recycle the array there and >>> account >>> >> >> for 3% of the benchmark in malloc/free there. In the same ballpark >>> >> >> _text_save_top account for 2% of the time in malloc/free. >>> >> >> >>> >> >> In that same benchmark, evas_object_textgrid_render account for 5% >>> >> >> where 4% of its time is spend in evas_common_font_draw_prepare. At >>> >> this >>> >> >> point I am not sure that rewriting textgrid is gona help us at >>> all. We >>> >> >> will win almost as much by just inlining the get_next things in >>> evas >>> >> >> and eina for a minute of development time. >>> >> > >>> >> > It's a bit naive to think so, because you'd be able to change the >>> >> algorithm >>> >> > and avoid conversions. All in all you could just give engine the same >>> >> array >>> >> > that terminology fills (cell row array), together with region and >>> context >>> >> > (clipper, cutouts) and glyph bitmap. >>> >> > >>> >> > Particularly the glyph bitmap could be optimized as its an int hash, >>> but >>> >> we >>> >> > know A-Za-z0-9 ate hot, we could have ASCII printable range in an >>> array >>> >> > while everything else goes to a hash >>> >> >>> >> Time spend in evas_common_font_draw 4%. Time spend in >>> >> evas_object_textgrid_*: > 2%. >>> >> Time spend in _cb_fb_read : 82% with evas_string_char_next_get being >>> >> 15% and memcpy 18%. >>> >> >>> >> I don't see how optimizing textgrid is going to change this number at >>> all. >>> > >>> > You'd not be doing these at all. That's why/how. >>> >>> What do you mean by "these" ? I am going to redo the benchmark with >>> perf on another computer to see if there is something else. >> >> >> These calls. If you do the way I imagine you give the screen (array of >> cells) to the render much like the way you give pixels to image. There is >> no need to call a bunch of things, like no need to create the text props >> and such. All you need is the cell info (palette index and attributes), the >> palette contents and a way to convert Unicode -> bitmap. > > All the cost of this 4% goes into the blitting, that you can't win. So > you are basically going after a 2% improvement, that you can maybe > reduce a little but not much as we don't create the text props at all > in more than 99% of the case and the text props is a mapping from > unicode to bitmap that are recycled very often. I really think you are > focusing on the wrong thing here.
You can allow engine to cache not only the glyphs, but the cells. (with bg/font colors, translating into pure image blit). Text grid is pretty cache friendly for one alphabet, and for terminology that will definitely hit ASCII as user data may be outside it, but compile output, commands and similar are all ASCII :-) You can have an array of printable elements and access them in O(1), no translation. And if you do such, the grid contents needs no special handling. It will be like an image, you can think about an image with different colorspace :-) as for the _cb_fd_read(), indeed it's outside of the concept of textgrid... and looking at it it's pretty obvious that should optimizations could be applied, simply by changing how it converts the chars to unicode, then handle it to handle_buf just to grow its buffer and copy. The (n == 0) block can also be simplified and optimized at the same time :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
