On Wed Mar 27 13:11:35 2013, doughera wrote: > > This is the tact I tried in commit f8fd8bfff8eb57156a0ab858d4c185701258b0e3 > in branch remotes/origin/smoke-me/andyd/croak_memory_wrap. > > I'd welcome feedback. I'm no longer sure it ends up saving anything > compared to the original Perl_croak_nocontext("%s", PL_memory_wrap), > but this seemed like the best way forward for now. > Summary, on Win32, new way (8 bytes) is slightly worse than before (5 or 7 bytes), but still better than the original situation (19 bytes). Its ok. On Win32 (not discussing any other OS), Perl_croak_memory_wrap is still a savings. On VC 2003 32 bit , it will now probably (I didn't compile f8fd8bfff8eb57156a0ab858d4c185701258b0e3) be ____________________________________________ jmp_conditional didnt_wrap (2 bytes) call *(image_import_table_Perl_croak_memory_wrap) (6 bytes) didn't_wrap: ____________________________________________ which is still shorter than ________________________________________________ jmp_conditional didnt_wrap (2 bytes) push *(image_import_table_PL_memory_wrap) (6 bytes) push in_image_%s_fmt_string (5 bytes) call *(image_import_table_Perl_croak_nocontext) (6 bytes) didn't_wrap: ________________________________________________ As a static non-inline previously, *ideally* (C compiler dependent) it would have been ________________________________________________ jmp_conditional relative_to_croak_memory_wrap (5 bytes) ________________________________________________ Visual C 2003 in 32 bit mode I remember did ________________________________________________ jmp_conditional didnt_wrap (2 bytes) jmp_unconditional in_image_S_croak_memory_wrap (5 bytes) didn't_wrap: ________________________________________________ which is strange and unideal, (I will guess, in the internal design of VC, it probably has to do with the 1st jump being a flow control bytecode op, and the 2nd jump being the func call bytecode op). In theory, a C compiler could do (VC will do this in debug mode to enable http://msdn.microsoft.com/en-us/library/bcew296c%28v=vs.80%29.aspx ), looking at my 5.12 Strawberry (GCC -O2), it does NOT do this) ________________________________________________ jmp_conditional relative_to_Perl_croak_memory_wrap_stub (5 bytes) didn't_wrap: ________________________________________________ somewhere else in the image, once per image, there is the following function ________________________________________________ jmp_unconditional *(image_import_table_Perl_croak_memory_wrap) (6 bytes) ________________________________________________ But I guess there is a performance problem with doing that so it just isn't done by any Windows C compiler in an optimized build. -- bulk88 ~ bulk88 at hotmail.com --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=116989Thread Previous | Thread Next