Re: [Vala] Help me find the right Vala idiom

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


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?

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.




Because this was just and example, to read the file I used an IOChannel,
today "the cool guys" will use GIO instead ;)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]