[gst-devel] [gst-cvs] tpm gstreamer: gstreamer/ gstreamer/gst/

[Tim Müller]

On Tue, 2007-11-06 at 21:46 +0200, Stefan Kost wrote:

> > * gst/gstdebugutils.c: (debug_dump_element),
> >   (_gst_debug_bin_to_dot_file), (_gst_debug_bin_to_dot_file_with_ts):
> >   Don't use VLAs which is a C99ism and throws off MSVC (#493983).
>
> Wouldn't that be a use case of g_alloca ?

g_alloca() would have been a possibility too, yes.  But since the patch
provided used g_malloc() and I personally have a strong dislike against
g_alloca() and we don't use it anywhere else in the core, I did not
change it.


> * gst/gst.c: (_gst_disable_segtrap):
>   Make  _gst_disable_segtrap static, it's only used in gstplugin.c and
>   we can use gst_segtrap_is_enabled() there now that we have that API.
>   Move _gst_debug_dump_dot_dir into gstdebugutils.c, there's no reason
>   to do the getenv here (and export the variable).
>
> Hmm, I don't think we want to call getenv each time we dump a graph?

Each time we dump a graph, we iterate through all elements and pads of a
bin or pipeline, take and release hundreds of locks in the process, do a
trizillion mallocs/frees/printfs, and WRITE TO DISK.  I fail to believe
that a single call to getenv() before all that is going to have a
significant performance impact.  If you have any evidence to the
contrary, I'd love to see it :)

 Cheers
  -Tim

PS: so what's next, a debate on the performance impact of ++i vs. i++?