[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
inline build_string performance
From: |
Paul Eggert |
Subject: |
inline build_string performance |
Date: |
Tue, 26 Jun 2012 07:53:51 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 |
Trunk bzr 108742 changed build_string from a standard
extern function to a static inline function:
static inline Lisp_Object
build_string (const char *str)
{
return make_string (str, strlen (str));
}
This is not an unalloyed win, since it bloats the
size of the Emacs executable, as callers to build_string
often now have two function calls (strlen + make_string),
not one (just build_string). In my environment
(Fedora 15 x86-64, GCC 4.7.1) this patch adds 5704 bytes (0.25%)
to the size of the Emacs text. Presumably this puts
a bit more pressure on the text cache.
Has a performance analysis been done on this change
showing that the code bloat is worth it?
While we're on the subject, I suspect that
we'll get more of a performance win by having a
function 'build_unibyte_string' in the common case
where build_string is invoked on text that is known
to be unibyte, as that avoids a separate pass through
the string. I haven't had time to investigate this,
though.
- inline build_string performance,
Paul Eggert <=
- Re: inline build_string performance, Andreas Schwab, 2012/06/26
- Re: inline build_string performance, Dmitry Antipov, 2012/06/26
- Re: inline build_string performance, Paul Eggert, 2012/06/26
- Re: inline build_string performance, Dmitry Antipov, 2012/06/26
- Re: inline build_string performance, Paul Eggert, 2012/06/26
- Re: inline build_string performance, Dmitry Antipov, 2012/06/26
- Re: inline build_string performance, Paul Eggert, 2012/06/26
- Re: inline build_string performance, Eli Zaretskii, 2012/06/26
- Re: inline build_string performance, Thien-Thi Nguyen, 2012/06/26
Re: inline build_string performance, Stefan Monnier, 2012/06/26