[gstreamer-bugs] [Bug 598896] [GstRegistry] Cache lists of ElementFactory and TypeFindFactory

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=598896
  GStreamer | gstreamer (core) | git

Sebastian Dröge <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slomo at circular-chaos.org

--- Comment #12 from Sebastian Dröge <slomo at circular-chaos.org> 2009-10-22 09:25:36 UTC ---
(In reply to comment #11)
> (In reply to comment #8)
> > Review of attachment 145766 [details] [details]:
> > 
> > What Tim said, use the GObject instance private stuff here. Not that it matters
> > much (because there's usually only one GstRegistry instance) but it's cleaner
> > ;)
> 
>   That private data code in gobject/gtype.c is ugly/slow beyond belief. Until
> that's fixed, I have no intention of adding that in optimisations.
>   I could definitely have a look at speeding up that gtype code though.

It's not going to make anything slower here because you get it once in your
instance_init as you do it now. Getting it always when you need it is far too
expensive for everything.

But you agreed to that on IRC already ;)

> (In reply to comment #9)
> > Review of attachment 145923 [details] [details]:
> > 
> > - Use g_list_alloc() instead of GSlice, you never know if GLib will change
> > allocations of list nodes again in the future
> > - You could use g_list_append() instead of the manual twiddling with the next
> > and prev pointers... unless the function call is too expensive for you :)
> > g_list_append() runs in O(1) if you append a new node to the last element btw
> > but you know that ;)
> 
>   I'm just wondering if it's worth it. Having to call two external functions
> (which do checks) over a list.. is basically gonna kill the optimisation.
>   I'm either completely removing it or keeping as is.

g_list_alloc() does no checks, it's just a wrapper around g_slice_new0() but if
you use it, nothing will break when GLib switches to GSlice2 or GSuperAllocator
:)

Argument for g_list_append() is fine though, just keep that code as is and only
call g_list_alloc().
The prev/next/data design of GList can't change anyway without breaking ABI/API

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.