Feature #11146: [PATCH] variable.c: initialize generic_iv_tbl at start

• Status: Closed
• Assignee: normalperson (Eric Wong)
• Target version: -

[normalperson (Eric Wong)]

Even miniruby creates one generic ivar (plain "ruby" creates 9),
so there's no point in lazily allocating the table and increasing
lines of code.

I'll commit in a few days unless there's objections.

I dumped generic ivar counts with the following trivial patch:

--- a/variable.c
+++ b/variable.c
@@ -24,6 +24,10 @@ static void check_before_mod_set(VALUE, ID, VALUE, const char *);
 static void setup_const_entry(rb_const_entry_t *, VALUE, VALUE, rb_const_flag_t);
 static int const_update(st_data_t *, st_data_t *, st_data_t, int);
 static st_table *generic_iv_tbl;
+__attribute__((destructor)) static void count_genivar(void)
+{
+    fprintf(stderr, "genivars: %zu\n", (size_t)generic_iv_tbl->num_entries);
+}

 void
 Init_var_tables(void)

[nobu (Nobuyoshi Nakada)]

• Description updated (diff)

Probably, due to @gem_prelude_index of $LOAD_PATH elements?

[normalperson (Eric Wong)]

[e-mail] wrote:

Probably, due to @gem_prelude_index of $LOAD_PATH elements?

That's one, but I think generic ivar is common enough. I'll also
work on using ivar index + array (like T_OBJECT) to reduce hash table
entries for most generic cases.

[ko1 (Koichi Sasada)]

On 2015/05/14 5:15, Eric Wong wrote:

That's one, but I think generic ivar is common enough. I'll also
work on using ivar index + array (like T_OBJECT) to reduce hash table
entries for most generic cases.

This is just curious.

How many generic ivar variables on practical applications, such as Rails
and so on?

--
// SASADA Koichi at atdot dot net

[normalperson (Eric Wong)]

SASADA Koichi [e-mail] wrote:

On 2015/05/14 5:15, Eric Wong wrote:

That's one, but I think generic ivar is common enough. I'll also
work on using ivar index + array (like T_OBJECT) to reduce hash table
entries for most generic cases.

This is just curious.

How many generic ivar variables on practical applications, such as Rails
and so on?

10 generic ivar for each accepted SSLSocket on servers.
I might have 30K accepted sockets...
(22 for each client connection!)

• Status changed from Open to Closed

Applied in changeset r50569.

---

variable.c: generic_iv_tbl is unavoidable

Even miniruby creates one generic ivar (plain "ruby" creates 9),
so there's no point in lazily allocating the table.

I dumped generic ivar counts with the following trivial patch:

--- a/variable.c
+++ b/variable.c
@@ -24,6 +24,10 @@ static void check_before_mod_set(VALUE, ID, VALUE, const char *);
static void setup_const_entry(rb_const_entry_t *, VALUE, VALUE, rb_const_flag_t);
static int const_update(st_data_t *, st_data_t *, st_data_t, int);
static st_table *generic_iv_tbl;
+attribute((destructor)) static void count_genivar(void)
+{

• fprintf(stderr, "genivars: %zu\n", (size_t)generic_iv_tbl->num_entries);
  +}

void
Init_var_tables(void)

• variable.c (Init_var_tables): init generic_iv_tbl
  (rb_generic_ivar_table, generic_ivar_get, generic_ivar_set,
  generic_ivar_defined, generic_ivar_remove,
  rb_mark_generic_ivar, givar_i, rb_mark_generic_ivar_tbl,
  rb_free_generic_ivar, rb_copy_generic_ivar, rb_ivar_foreach,
  rb_ivar_count): remove checks for uninitialize generic_iv_tbl
  [ruby-core:69155] [Feature #11146]