Hi, I was reffering to the idea Matthis Clasen mentioned in this thread: http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00169.html
I look at my own application. Refdbg tells me that I use 162 different types. So the overhead seems to be acceptable. Running oprofile shows these two top in the report for libgobject which itself has 7 % of the total time. 168 11.2299 g_type_check_instance_is_a 118 7.8877 g_type_is_a Nothing big to gain here, so it seems. Stefan Quoting Tim Janik <[EMAIL PROTECTED]>: > On Mon, 7 May 2007, Stefan Kost wrote: > >> hi, >> >> wasn't the g_type_register_static_simple() meant to avoid the memcpy() >> of filling the GTypeInfo only to pass it to type_data_make_W, which >> then copies most filed from this elsewhere? > > no, the code in question is not time critical in the sense that you'd > ever notice a structure memcpy or not. it's not like you could call it > in a loop for several million times to expose a timing difference. > >> Then shouldn't type_data_make_W() be reflowed. There is a big if() >> elseif(), elseif() else in there. Implementations should know if what >> the instance is instantiable, classed or an interface. They could >> directly call instantiable_type_data_make_W(), >> classed_type_data_make_W(), ... and these make some unconditional >> calls at top/bottom to share common functionality. > > huh? do you want to forbid conditionals in code from now on, or what > is this about? i don't see a reason to "reflow" type_data_make_W(), > whatever it is you mean by that ;) what you suggest sounds way more > complex than the current code. > there is simply no need to tear the code apart and you are not > providing a rationale for doing it. > >> Then its the >> question wheter the specific variants could avoid the copy from >> GTypeInfo to InstanceData, ClassData or IFaceData. Couldn't they also >> receive the GtypeInfo fields as parameters? > > what's this "avoid copy of a handful structure fields" about? > i highly doubt that you can provide any data that an int-copy or > a bunch of pointer-copies in run-once code have a severe performance > impact. > in any case, such data would have to be presented first, before we talk > about particular code changes. that's so we can avoid premature > optimizations and adress real problem areas: > http://en.wikipedia.org/wiki/Premature_optimization#When_to_optimize > >> Stefan > > --- > ciaoTJ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
