On Sun, 2009-08-02 at 16:20 +0200, Jiří Zárevúcky wrote:
> On 08/01/2009 08:14 PM, Hans Vercammen wrote:
> > Using weak/unowned is mainly intended for the bindings and in case you
> > need to break cycles to prevent memory leaks. Furthermore weak/unowned
> > variables could potentially create dangerous dangling pointers as there
> > is no certainty the memory pointed to is valid (think multi-threaded for
> > example).
> 
> Potentially, yes. But experienced programmer would have no problem with 
> that.
> If there is no way the problem could ever happen, why not use some 
> optimizations?

The problem with language features that are only required in very rare
cases, is that they get abused by people who think they can outsmart the
compiler and go complain afterwards things are not working correctly.
This is not intended at you personally Jiří, just an observation :) Vala
is designed to be simple with a straightforward ABI and provide a
standard way of automatic (assisted) memory management. There are corner
cases where performance is critical and could use some optimization.
However, optimizing without knowing exactly how your C compiler
optimizes loops and cache line usage is mostly premature optimization
(also called the root of all evil). So why go through all that trouble?
You should be focused on the vala code, not the C code :)

> >   The overhead of reference counting is usually neglectable as
> > those interfaces are most likely in the cache already. For non-reference
> > counted types, you probably want the use transfer ownership or as Jürg
> > suggested write a nice GObject library on top that plays well with the
> > rest of the stack. And then there is also the possibility of using
> > pointers in vala, but then you are basically on your own without any
> > guaranties.
> >    
> 
> That's true for unowned as well.
> 
> > As you seem to claim that "Assigning to a ref-counted variable is twelve
> > times (!) slower then a pointer assignment." I would be very interested
> > in detailed profiling info to support that, or at least showing that
> > this is causing a significant slower program :)
> >
> >    
> 
> Well, that's a very rough measurement taken by timing a loop. Not quite 
> precise, but does show a significant difference.
> How it affects a real program is an entirely different question. I've 
> created a simple exemplary application that analyzes an XML tree. It 
> relies heavily on iteration and so far the difference in total running 
> time is roughly 3-4%. So I guess it's not really significant in most cases.
> 
> Yet, I'm kinda wondering about one thing. It seems to me some people 
> were, are and will be wanting inference for weak variables, regardless 
> the real benefits may be negligible. Even if it were just to have nice C 
> code where the reffing is not needed. Still, every time the question 
> comes up, people will spend much more time arguing the insignificance 
> then it would take to actually implement it... Quite

C programmers tend to be lazy you know, they rather type less and not
have to free or unref return values etc. (Which also causes many leaks,
within C programs. Think of warn_unused_result gcc attributes for
example) But as you may know, vala is different and does all this
tedious work for you :)

Regards,
Hans

_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list

Reply via email to