On Tue, 2012-03-06 at 10:44 +0000, Chris Elston wrote: > Thanks to both Mark and Andrea for taking the time to look at this for > me.
YW > > Mark's solution is good because it looks to me like pretty clean OO > without using GObject introspection. I'm not sure on the cost of I was sure that someone would suggest an OO oriented solution like Mark did, so I came up with a different approach :) > wrapping each fundamental type in a parse class though. How much memory > does each of those wrapping class instances take up when my config class > might have hundreds of them? Few KB? And you can instantiate these classes only during the parsing of the config and release the memory after that. > > I like Andreas solution too, particularly because it separates the > business of parsing the data from the target class to be instantiated > with the data. It also seems like it would scale better because the > fundamental types in ConfigData aren't wrapped in another class. Yes, but I bet that my code is worse performance wise. Take in mind that when I search and assign a property I do 2 lookups in the object property table. As I said I traded performance and flexibility for a minimal and easy to use API. (For example a config class must define all the options as properties and not simple fields, it must derive from GObject etc...) > > Some quick profiling shows that Andrea's solution gives a binary about > 2.5 times bigger and about half as fast as the C (for 100 iterations). > Although Andrea's solution is also doing more error checking than my > quick and dirty example. Is this fairly typical of Vala code. Can anyone > comment on how much of that is down to Vala and how much is down to > GObject? i.e.: if I were to write equivalent GObject C, would I get > similar performance and size to the compiled Vala code? IMHO: vala GObject code is more or less like C GObject code performance wise but not size wise (I GObject-C you can decide the amount of checking, copying you'll do/write, with vala all this code is always generated even if not required). On the other side I think that GCC optimizations will catch and solve most of these problems. > > Cheers, > > Chris. Ciao, Andrea P.S. Because this was just and example, to read the file I used an IOChannel, today "the cool guys" will use GIO instead ;) _______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
