GNOME Bugzilla – Bug 564016
add nsprefix to gir and typelib
Last modified: 2015-02-07 16:45:09 UTC
We could speed up _find_by_gtype quite a lot if we included the "nsprefix" inside the typelib. In a lot of cases this would mean only looking in one typelib instead of all of them.
The main case where you'd have to look in multiple typelibs is looking up "GSomething" - could be in GObject, or Gio. Still though, probably a large win.
Alternatively, we could have a global cache with entries like this; With a typename -> fully qualified name, eg: GtkButton -> entry(typelib name, [typelib + offset]) And when loading a typelib we'd populate that cache with all known gtype names. insert_typelib would be this: - g_hash_table_insert(typelib_name, typelib) - for each gtype - g_hash_table_insert(type_names, [type_name + offset]) find_by_gtype would be this: - g_type_name(gtype) -> type_name - g_hash_table_lookup(type_name) -> qualified name - split qualified name -> [typelib + offset] - g_hash_table_lookup(typelib name) - create & return GIBaseInfo Would that work?
That would mean a large chunk of writable memory for each process. The current cache is proportional to the number of GTypes seen by a program, whereas your suggestion is proportional to all GTypes.
Right. We'd probably need some numbers here to make a qualified decision. If the total number of GTypes available in a program is less than say 200, it would probably make sense. Dedicating say 4kB writable memory per process for this kind of lookup optimizations is quite reasonable.
Created attachment 128599 [details] [review] Bug 564016 - Add c:prefix to .gir This has a few use cases; the main one in mind right now is that when we place this in the .typelib as well, we can use it to optimize lookups based on GType names, by skipping entirely typelibs whose c:prefix is not a prefix of the target type lookup.
Created attachment 128604 [details] [review] Bug 564016 - Include c:prefix in typelib, use it to optimize find_by_gtype Parse the c:prefix from the .gir, include it in the header. Armed with this information, we can now optimize lookups of GTypes because we have the requirement that GTypes must start with the c:prefix.
Other reasons to include the c:prefix in the .gir is that it would allow us to eliminate the c:type from pretty much everything, because we know that c:prefix + giname == c:type.
Comment on attachment 128604 [details] [review] Bug 564016 - Include c:prefix in typelib, use it to optimize find_by_gtype Looks good
Created attachment 130784 [details] [review] Bug 564016 - Add c:prefix to .gir This has a few use cases; the main one in mind right now is that when we place this in the .typelib as well, we can use it to optimize lookups based on GType names, by skipping entirely typelibs whose c:prefix is not a prefix of the target type lookup.
Created attachment 130785 [details] [review] Bug 564016 - Include c:prefix in typelib, use it to optimize find_by_gtype Parse the c:prefix from the .gir, include it in the header. Armed with this information, we can now optimize lookups of GTypes because we have the requirement that GTypes must start with the c:prefix.
Ok, these patches work well except they break the gjs test suite. The reason for this is that the tests/everything uses the namespace "Everything", but in fact everything inside there is prefixed with "Test". I'm inclined to say we should fix the everything library; a test library we ship should conform to good GObject conventions. Opinions?
Yes, everything should be fixed.
I had a simpler fix (and what we need to do anyways for the Clutter/Cogl case), is that we should fall back to searching all typelibs if the nsprefix lookup fails.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]