[gst-devel] [gst-cvs] tpm gstreamer: gstreamer/ gstreamer/gst/
t.i.m at zen.co.uk
Tue Nov 6 22:26:26 CET 2007
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
> * 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 :)
PS: so what's next, a debate on the performance impact of ++i vs. i++?
More information about the gstreamer-devel