[Vala] Tons of _tmpX_ variables and other performance issues
- From: "marcin saepia net" <marcin saepia net>
- To: vala-list gnome org
- Subject: [Vala] Tons of _tmpX_ variables and other performance issues
- Date: Wed, 22 Feb 2012 15:52:10 +0100
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]