IIRC, the Ecore_List2 code actually embeds the list at the head of a struct. From the standpoint of the number of allocations occurring, this is much more efficient, but it doesn't allow you to optimize access to the end of the list unless you include an extra pointer in each node on the list like the evas lists. Which means your structure is now larger and uses more memory per-node.
It all comes down to your use pattern. From a memory standpoint, if you are dealing with something like an LRU queue of any reasonable length, Ecore_List is probably what you want. If you need to keep references to points within a list, use an Evas_List. If you need to minimize the number of allocations for a specific case, then something like Ecore_List2 is probably your best bet.
I don't think there is a very cohesive plan on list use atm. I've heard a few rumblings of people saying "ecore lists suck" or "evas lists suck" but as usual it's a case of choosing the best tool for the job and knowing when each is appropriate.
On 1/2/06, David Seikel <[EMAIL PROTECTED]> wrote:
On Mon, 2 Jan 2006 22:11:23 +1000 David Seikel <[EMAIL PROTECTED]>
wrote:
> On Mon, 02 Jan 2006 12:53:58 +0100 Morten Nilsen < [EMAIL PROTECTED]>
> wrote:
>
> > David; you might want to absorb the ecore_exe part of this patch
> > into your current work :)
>
> It's next on my list to look it your patch after my current task.
> Unless something more important comes up, like a bug I need to fix.
I've looked over your ecore_exe patch, and did some research. I've
come to the conclusion that I have no idea what the plans are
concerning converting ecore to use Ecore_List. I have seen
evidence that some people think Ecore_List is too heavy weight.
I'm out of the loop on that aspect of the code, so I'll leave the
decision making on these patches to wiser heads.
