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. > -- > Cedric BAIL > > > ------------------------------------------------------------------------------ > 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 <javascript:;> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- 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
