Hi,
I finally got some more time to take a look at the memory management of
eet
and evas.
On Thursday 23 March 2006 03:29, Carsten Haitzler wrote:
> On Wed, 22 Mar 2006 16:53:07 +0100 Cedric <[EMAIL PROTECTED]> babbled:
> > On Wednesday 22 March 2006 12:40, Carsten Haitzler wrote:
[sni
On Thursday 23 March 2006 03:30, Carsten Haitzler wrote:
> On Wed, 22 Mar 2006 15:03:51 +0100 Cedric <[EMAIL PROTECTED]> babbled:
> > On Wednesday 22 March 2006 01:03, you wrote:
> > > Looking forward to your benchmarks.
> >
> > I have access to another computer (P4 3.2Ghz) and made another attempt
On Wed, 22 Mar 2006 16:53:07 +0100 Cedric <[EMAIL PROTECTED]> babbled:
> On Wednesday 22 March 2006 12:40, Carsten Haitzler wrote:
> > [ 8:35PM ~/t ] ./t ~/.e/e/applications/all/*
> > 2.13070
>
> > now with plain malloc as-is in cvs for eet:
>
> > [ 8:35PM ~/t ] ./t ~/.e/e/applications/all/*
>
On Wed, 22 Mar 2006 15:03:51 +0100 Cedric <[EMAIL PROTECTED]> babbled:
> Oups, forgot devel list.
>
> -- Forwarded Message --
>
> Subject: Re: [E-devel] Memory pool management
> Date: Wednesday 22 March 2006 14:37
> From: Cedric <[EMAIL PROTE
On Wednesday 22 March 2006 12:40, Carsten Haitzler wrote:
> [ 8:35PM ~/t ] ./t ~/.e/e/applications/all/*
> 2.13070
> now with plain malloc as-is in cvs for eet:
> [ 8:35PM ~/t ] ./t ~/.e/e/applications/all/*
> 2.04144
> it's actually a tiny bit faster. (and consistently so)... so - i'm
> wonde
sorry, forget the list :S2006/3/22, QliX=D! [aka Ezequiel Brizuela] <[EMAIL PROTECTED]>:
I think in a rewrite of the garbage collector to get a full benefit of performance of realloc in glibc (specially in linux that support MREMAP), Let me Introduce:The implementation of realloc is as follows:
Fr
Oups, forgot devel list.
-- Forwarded Message --
Subject: Re: [E-devel] Memory pool management
Date: Wednesday 22 March 2006 14:37
From: Cedric <[EMAIL PROTECTED]>
To: "Nathan Ingersoll" <[EMAIL PROTECTED]>
On Wednesday 22 March 2006 01:03, you wrote:
>
On Wed, 22 Mar 2006 12:14:58 +0100 Cedric <[EMAIL PROTECTED]> babbled:
> On Wednesday 22 March 2006 03:57, Carsten Haitzler wrote:
> > have you tested ememoa heavily? i'm getting assert failures with this
> > small test program i whipped up to see if what you say about this
> > speeding up things
On Wed, 22 Mar 2006 12:14:58 +0100 Cedric <[EMAIL PROTECTED]> babbled:
> On Wednesday 22 March 2006 03:57, Carsten Haitzler wrote:
> > have you tested ememoa heavily? i'm getting assert failures with this
> > small test program i whipped up to see if what you say about this
> > speeding up things
On Wednesday 22 March 2006 03:57, Carsten Haitzler wrote:
> have you tested ememoa heavily? i'm getting assert failures with this
> small test program i whipped up to see if what you say about this
> speeding up things like displaying menus (which loads a lot of edje
> objects - thus a lot of eet a
Wasn't something like this already being implemented on evas? IIRC
raster where experimenting with it, i did some test with memory pools
and lots of profiling, memory pools do work suprisling well on linked
list, specially on big ones doing iterations, elements in contiguous
memory access are faste
On Wed, 22 Mar 2006 00:35:23 +0100 Cedric BAIL <[EMAIL PROTECTED]> babbled:
> Le Mardi 21 Mars 2006 22:21, Nathan Ingersoll a écrit :
> > I think people are interested in this, but it's difficult to generate
> > enthusiasm without some numbers to show why this is worthwhile. Some
> > simple benchm
On 3/21/06, Cedric BAIL <[EMAIL PROTECTED]> wrote:
>
> I have already used the same approch in anoser project that heavily
> used
> malloc (an assembler, http://savannah.nongnu.org/projects/aasm/) and the win
> was quite impressive compared to malloc (around 10 times faster). But this
> wa
Le Mardi 21 Mars 2006 22:21, Nathan Ingersoll a écrit :
> I think people are interested in this, but it's difficult to generate
> enthusiasm without some numbers to show why this is worthwhile. Some
> simple benchmarks to show how much improvement this has on common
> cases, like lists, would be he
I think people are interested in this, but it's difficult to generate
enthusiasm without some numbers to show why this is worthwhile. Some
simple benchmarks to show how much improvement this has on common
cases, like lists, would be helpful.
Also, have you compared this against g_slice performance
On Tue, 21 Mar 2006 21:01:16 +0100 Cedric BAIL <[EMAIL PROTECTED]>
wrote:
> I have maid with the help of Olivier a little library that
> could, I hope, improve memory management in enlightenment.
There has been an ongoing memory management discussion for quite some
time at http://edevelop.o
Hi,
I have maid with the help of Olivier a little library that could, I
hope,
improve memory management in enlightenment.
The idea behind it was to provide a fast allocator which improve data
locality when manipulating the same object. For that purpose, the library
provide a s
17 matches
Mail list logo
