Re: Proposal: immediate strings

On 05/24/2012 11:14 AM, Stefan Monnier wrote:

>> That might work.  But this raises another idea: assuming most tiny strings
>> don't have text properties, won't it improve performance overall if
>> any string with text properties is forced to be an ordinary string, so
>> that immediate strings can reuse the rarely-used 'intervals' member
>> for data?
>
> That's part of the reason why I'm interested in his statistics about
> which strings have text properties.

YMMV since it depends on what happens. For a long byte-compile runs,
~0.05% - 0.1% of live strings may have text properties. On the other
side, some editing operations may cause this percentage to grow; for
example, (indent-region) in C mode buffers for a huge regions (a size
of xdisp.c :-) gives ~15% of live strings with properties, and almost
all of them are small (less than 16 bytes).

BTW, is it possible to attach a properties to a string used to represent
a symbol name? If not, we can drop some bits from mark_object at the
cost of having some precautions in Fmake_symbol.

Dmitry


=== modified file 'src/alloc.c'
--- src/alloc.c 2012-05-25 18:19:24 +0000
+++ src/alloc.c 2012-05-28 11:18:45 +0000
@@ -3211,6 +3211,9 @@
 
   MALLOC_BLOCK_INPUT;
 
+  if (!NULL_INTERVAL_P (STRING_INTERVALS (name)))
+    name = build_string (SDATA (name));
+
   if (symbol_free_list)
     {
       XSETSYMBOL (val, symbol_free_list);
@@ -5691,7 +5694,9 @@
   }
  if (!PURE_POINTER_P (XSTRING (ptr->xname)))
   MARK_STRING (XSTRING (ptr->xname));
- MARK_INTERVAL_TREE (STRING_INTERVALS (ptr->xname));
+
+ /* Symbol name should have no properties.  */
+ eassert (NULL_INTERVAL_P (STRING_INTERVALS (ptr->xname)));
 
  ptr = ptr->next;
  if (ptr)