Thank you for taking the time to do this!

> The GCC specific [cold](https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Function-Attributes.html) function attribute works in the following way (from GCC docs):

Since it's gcc (and clang); can we just use something like what
Linux uses:

  #define __cold			__attribute__((__cold__))

Instead of our ugly convention of: COLD( required prototype goes here );

It would allow us to be more DRY by avoiding prototypes for
static functions.

> By declaring a function as `cold` when defined we get the following benefits:
> 
> * No-op on platforms that does not support the attribute
> * Size optimization of cold functions with a smaller footprint in the instruction cache

Very much agreed.  I've always hated the icache footprint from -O3
since so much of our code is rarely executed.

Another benefit is it helps document code paths as to which ones
are most critical :>

> #### Extension APIs flagged as cold
> 
> These are and should typically only be called on extension init, and thus safe to optimize for size as well.
> 
> * `void rb_define_method(VALUE,const char*,VALUE(*)(ANYARGS),int));`

Does this affect startup performance?  (with --disable=gems)

> * Ruby binaries built with O3 and debug symbols come in at
> just short of 18MB, or roughly 9 hugepages on linux. PHP core
> developers were able to squeeze a few % by remapping code to
> hugepages on supported systems -
> http://developers-club.com/posts/270685/ . Implementation
> [here](https://github.com/php/php-src/blob/fb0389b1010de5a6459bcf286409423f69e74aaf/ext/opcache/ZendAccelerator.c#L2645-L2750)

Cool.  While THP is a disaster for CoW and anonymous mappings;
it makes perfect sense for large read-only mappings

Now, the question is; shouldn't this be done in ld-linux.so
(part of glibc) instead?

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>