load.c: lightweight loaded features index #264

Closed
wants to merge 1 commit into
from

Projects

None yet

3 participants

@funny-falcon
  • load.c use lightweight structure for loaded features index
    since loaded_feature_path checks name of feature, there is no
    need to store feature string in an index - only hash value
    is stored. And used hash structure need only one memory chunk,
    so that there is no need for memory allocation per feature.
    Offsets in LOADED_FEATURES could be organized in many
    single linked lists inside of single allocated array, to
    avoid many memory allocations.
    And since there is no referred Ruby objects, there is not impact
    on GC.
@eregon eregon and 1 other commented on an outdated diff Mar 24, 2013
load.c
{
- struct st_table *features_index;
- VALUE this_feature_index = Qnil;
- char *short_feature_cstr;
+ /* with -O2 even on i306 gcc and clang transform this to
@eregon
eregon Mar 24, 2013 Ruby Programming Language member

i386 maybe?

@funny-falcon
funny-falcon Mar 24, 2013

Yeah, you are right :) I was typing in a dark

@funny-falcon funny-falcon load.c: lightweight loaded features index
* load.c use lightweight structure for loaded features index
  since loaded_feature_path checks name of feature, there is no
  need to store feature string in an index - only hash value
  is stored. And used hash structure need only one memory chunk,
  so that there is no need for memory allocation per feature.
  Offsets in LOADED_FEATURES could be organized in many
  single linked lists inside of single allocated array, to
  avoid many memory allocations.
  And since there is no referred Ruby objects, there is not impact
  on GC.
c810ac7
@zzak
Member
zzak commented Apr 5, 2013

@funny-falcon Thanks for the report and patch, I've uploaded your patch to redmine so we can close this ticket to continue discussion on Feature #8158

@zzak zzak closed this Apr 5, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment