[Vala] Tons of _tmpX_ variables and other performance issues



Hi,

I am big fan of vala and I use it for many projects. Thanks for great work!

But when I dig into C code generated by valac I see tons of _tmpX_
variables with obviously unnecessary assignments. I mean cases like
this, when vala code like this:


Logger.debug(@"[func $(parent.parent.identifier) $(parent.identifier)]
Sending data [ $(sent_byte1) | $(sent_byte2) | $(sent_byte3) |
$(sent_byte4) ]");


turns into following C code:

        _tmp15_ = _tmp14_;
        _tmp16_ = string_to_string (_tmp15_);
        _tmp17_ = g_strdup_printf ("%c", sent_byte1);
        _tmp18_ = _tmp17_;
        _tmp19_ = g_strdup_printf ("%c", sent_byte2);
        _tmp20_ = _tmp19_;
        _tmp21_ = g_strdup_printf ("%c", sent_byte3);
        _tmp22_ = _tmp21_;
        _tmp23_ = g_strdup_printf ("%c", sent_byte4);
        _tmp24_ = _tmp23_;
        _tmp25_ = g_strconcat ("[func ", _tmp12_, " ", _tmp16_, "] Sending
data [ ", _tmp18_, " | ", _tmp20_, " | ", _tmp22_, " | ", _tmp24_, "
]", NULL);
        _tmp26_ = _tmp25_;
        my_logger_debug (_tmp26_);

I assume that this kind of code is a result of internal logic of
valac, but isn't it possible to avoid such things like "_tmp26_ =
_tmp25_"?

I am afraid that they unnecessary affect the performance (in average
valac output there are tons of assignments like that mentioned above)
- or maybe gcc is smart enough to optimize them?

If gcc won't do that, are there any plans to optimize that in valac?


Other case is string_to_string function

static const gchar* string_to_string (const gchar* self) {
        const gchar* result = NULL;
        g_return_val_if_fail (self != NULL, NULL);
        result = self;
        return result;
}


shouldn't it be generated as an inline function?

Thank you,

PS. I use valac 0.14

-- 
Marcin



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