On Mon, Feb 13, 2012 at 7:20 PM, Janne Blomqvist <blomqvist.ja...@gmail.com> wrote: > Hi, > > the attached patch changes the low-level libgfortran IO dispatching > mechanism to use shared vtables for each stream type, instead of all > the function pointers being replicated for each unit. This is similar > to e.g. how the C++ frontend implements vtables. The benefits are: > > - Slightly smaller heap memory overhead for each unit as only the > vtable pointer needs to be stored, and slightly faster unit > initialization as only the vtable pointer needs to be setup instead of > all the function pointers in the stream struct. > > - Looking at unix.o with readelf, one sees > > Relocation section '.rela.data.rel.ro.local.mem_vtable' at offset > 0x15550 contains 8 entries: > > and similarly for the other vtables; according to > http://www.airs.com/blog/archives/189 this means that after relocation > the page where this data resides may be marked read-only. > > The downside is that the sizes of the .text and .data sections are > increased. Before: > > text data bss dec hex filename > 1116991 6664 592 1124247 112797 > ./x86_64-unknown-linux-gnu/libgfortran/.libs/libgfortran.so > > After: > > text data bss dec hex filename > 1117487 6936 592 1125015 112a97 > ./x86_64-unknown-linux-gnu/libgfortran/.libs/libgfortran.so > > > The data section increase is due to the vtables, the text increase is, > I guess, due to the extra pointer dereference when calling the IO > functions. > > Regtested on x86_64-unknown-linux-gnu, Ok for trunk, or 4.8?
Certainly not for trunk at this stage. For 4.8: So the trade-off is between faster initialization and smaller heap vs. fewer pointer dereferences? Does this patch fix an actual problem? Does it bring a killer feature? Otherwise, I'd say "if it ain't broke, don't fix it!" Ciao! Steven
