On Thu, Jan 17, 2013 at 9:37 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> 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:;>> 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. -- 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 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
