From: Dmitry Antipov <dmantipov@yandex.ru>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Emacs Development <Emacs-devel@gnu.org>
Subject: Re: inline build_string performance
Date: Tue, 26 Jun 2012 21:33:34 +0400 [thread overview]
Message-ID: <4FE9F26E.6010700@yandex.ru> (raw)
In-Reply-To: <4FE9E691.9090906@cs.ucla.edu>
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
On 06/26/2012 08:42 PM, Paul Eggert wrote:
> That sounds worthwhile for critical paths.
>
> How about reverting the build_string change, and defining a new
> inline function build_literal intended for when the argument is a
> string literal and for when speed is more important than conserving
> code space? That would give us speed where speed matters and where
> we know it'll be faster, while avoiding code bloat otherwise.
> build_string and build_literal would have identical semantics,
> but different performance properties.
This may be implemented without reverting previous stuff. It will also gives
other (non-GCC) compilers a chance to demonstrate their optimization skills.
Dmitry
[-- Attachment #2: literal.patch --]
[-- Type: text/plain, Size: 1556 bytes --]
=== modified file 'src/alloc.c'
--- src/alloc.c 2012-06-26 14:41:01 +0000
+++ src/alloc.c 2012-06-26 17:26:02 +0000
@@ -2533,6 +2533,25 @@
return string;
}
+/* Fast version used when both STR and NBYTES are compile-time
+ constants, and all characters from STR are ASCII. */
+
+Lisp_Object
+build_literal (const char *str, ptrdiff_t nbytes)
+{
+ Lisp_Object string;
+ struct Lisp_String *s;
+
+ eassert (nbytes > 0);
+
+ s = allocate_string ();
+ allocate_string_data (s, nbytes, nbytes);
+ memcpy (s->data, str, nbytes);
+ string_chars_consed += nbytes;
+
+ XSETSTRING (string, s);
+ return string;
+}
\f
/***********************************************************************
=== modified file 'src/lisp.h'
--- src/lisp.h 2012-06-26 05:00:30 +0000
+++ src/lisp.h 2012-06-26 17:24:48 +0000
@@ -2716,12 +2716,28 @@
/* Make a string from the data at STR, treating it as multibyte if the
data warrants. */
+#ifdef __GNUC__
+
+extern Lisp_Object build_literal (const char *str, ptrdiff_t nbytes);
+
+#define build_string(str) \
+ ({ Lisp_Object __val; \
+ if (__builtin_constant_p (str) && strlen (str) > 0) \
+ __val = build_literal (str, strlen (str)); \
+ else \
+ __val = make_string (str, strlen (str)); \
+ __val; })
+
+#else
+
static inline Lisp_Object
build_string (const char *str)
{
return make_string (str, strlen (str));
}
+#endif
+
extern Lisp_Object pure_cons (Lisp_Object, Lisp_Object);
EXFUN (Fgarbage_collect, 0);
extern void make_byte_code (struct Lisp_Vector *);
next prev parent reply other threads:[~2012-06-26 17:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-26 14:53 inline build_string performance Paul Eggert
2012-06-26 15:17 ` Andreas Schwab
2012-06-26 16:29 ` Dmitry Antipov
2012-06-26 16:42 ` Paul Eggert
2012-06-26 17:33 ` Dmitry Antipov [this message]
2012-06-26 17:37 ` Paul Eggert
2012-06-26 17:58 ` Dmitry Antipov
2012-06-26 18:46 ` Paul Eggert
2012-06-26 20:41 ` Eli Zaretskii
2012-06-26 18:51 ` Thien-Thi Nguyen
2012-06-27 0:39 ` Stefan Monnier
2012-06-27 3:02 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FE9F26E.6010700@yandex.ru \
--to=dmantipov@yandex.ru \
--cc=Emacs-devel@gnu.org \
--cc=eggert@cs.ucla.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.