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. -- 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
