Copying property information

[Owen Taylor <otaylor redhat com>]

> > 50212  Copying param information is not necessary [X]
> >   Notes:    Alex is looking into quantifying the wastage here.
> >   Puntable: 
> >   Breakage: Theoretical, probably not actual.
> >   Time:     5 minutes + time to decide
> 
> the time estimated here is a gross misguess. issues involved:
> 1) API consistency, we don't take over user strings anywhere in
>    our API without loud flagging of doing so, examples:
>    g_quark_from_static_string(),
>    g_value_set_string_take_ownership()
>    so if we change current matters at all we basically have two options:
>    - we silently assume that the strings passed into current API are
>      static and don't duplicate them. this will raise millions of
>      questions on why we don't do the same in other possible places.
>      i.e. special flagging mentioned above (g_querk_from_static_string())
>      becomes pointless, and duplicating strings passed in to
>      gtk_type_unique(), g_type_register_static() or
>      g_type_register_dynamic() also becomes pointless.
>      especially the latter one will be an issue however, since frequently
>      the string passed in to g_type_register_dynamic() will come from
>      unloadable data sections.

As you are well aware, I'm not suggesting that we start not copying
all strings passed in. I'm suggesting that a little bit of documented
inconsistency may be worth it to save 30k of memory per program.

(Yes, this figure was for all widgets, so an overestimate, but our
description fields and sets of properties are not at all complete, and
people  will be using widgets from other libraries as well, so it
is an underestimate as well.)

>    - we flag g_param_spec_int() and friends as in other API, this will
>      produce monsters of function names however, e.g.:
>      g_param_spec_int_static_strings()
>      these could at least be provided in parallel to existing API
>      g_param_spec_int() so change can occour gradually.

The change that would occur "gradually" would be running a single
sed script over GTK+. Which is, of course, why it's not that great
an idea. Why should the function that people are using all of the time
function be named something like g_param_spec_int_static_strings()?

>    - we already have means to handle taking over static strings, that
>      of special name flagging of such function, so there's no actual
>      need to break with established conventions and ruin API
>      consistency once more

Well, we have a method that would confuse people and make every 
virtually every program using GParamSpec look really bad for no
good reason.

> 3) the breakage involved won't be huge for gtk proper i assume, but i
>    guess there's a bunch of (plugin) code in beast that'll have to
>    change if we broke semantics of currently existing functions

I very much doubt that plugins in beast have properties that outlive
the classes they are attached to.... I suppose there is the theoretical
possiblity of someone calling g_param_spec_ref() on a param spec from
a dynamically loaded class, then unref-ing the class. But this strikes
me as being very much a corner case that is not worth worrying about
much compared to the main efficiency 


But, before we get too deep into arguing this, we probably should back 
off a step and look at our other efficiency problem with property
descriptions, though it is one that won't show up that much in
profiling, unless you start profiling with LANG=de_DE :-)

===
  g_object_class_install_property (gobject_class,
				   PROP_NAME,
				   g_param_spec_string ("name",
 							_("Widget name"),
							_("The name of the widget"),
							NULL,
							G_PARAM_READWRITE));

#: gtk/gtkwidget.c:392
msgid "Widget name"
msgstr "Widgetname"

#: gtk/gtkwidget.c:393
msgid "The name of the widget"
msgstr "Der Name des Widgets"
====

So, to add this property, we:

 - Look up "Widget name" in the .po file
 - Create a malloced entry in a gettext internal tree at an expense
   of something like 49 +  msgid_len + domain_len bytes 
 - Make a copy of the result and store it in the property 

 - Repeat this all for "The name of the widget"

So, the total memory usage is   

 (strlen ("Widget name") + strlen ("The name of the widget" + 
  strlen ("Widgetname" + strlen ("Der Name des Widgets") + 4*2 + 49 * 2)  

So, something like 170 bytes for a very conservatively documented property.
It could easily have been:

#: gtk/gtklabel.c:228
msgid ""
"The alignment of the lines in the text of the label relative to each other. "
"This does NOT affect the alignment of the label within its allocation. See "
"GtkMisc::xalign for that."
msgstr "
"Die Ausrichtung der Zeilen im Beschriftungstext untereinander. Dies betrifft"
"NICHT die Ausrichtung der Beschriftung innerhalb ihres Verfügungsraumes; dafür"
"siehe auch GtkMisc::xalign."

Spending 300-400 bytes of malloc'ed memory plus time overhead) to hold information
that we need NEVER for a normal programs seems pretty excessive.

My conclusion from this is that we really need a way to look up property
names and descriptions lazily. A quick suggestion would be:

  g_type_set_doc_file (GTK_TYPE_WIDGET, OBJDOCDIR G_TYPE_SEPARATOR_S "gtkwidget.objdoc");

  g_object_class_install_property (gobject_class,
				   PROP_NAME,
				   g_param_spec_string ("name", NULL, NULL,
							NULL,
							G_PARAM_READWRITE));

And add g_param_spec_get_nick/blurb() that looks up the information frmo the .objdoc file
for paramspec->owner_type.

<od:class name="GtkLabel">
  <od:textdomain domain="gtk20"/>
  <od:property name="name">
    <od:nick>Widget Name</od:nick>
    <od:blurb>
      The name of the widget
    </od:blurb>
  </od:property>
</od:class> 

(Yes, that could be done as sexps, if you really want to fight the standardization tide.)


In fact, I believe this is the right way  to do things, so I'm willing to concede
on the issue of copying the strings for g_param_spec_string() ... the wins for
not copying there are small compared to what we can get by lazily looking up the 
nick/blurb.

The only thing I think we can't punt on this "move docs to files" issue is to
add the accessors for nick/blurb and mark the corresponding fields private. If
we don't do that, then we can't add lazy lookups later.

Regards,
                                        Owen