Yes, it has been resolved (probably by D10981).

@segfaultxavi Can you please confirm if this one is resolved?

@brokenshakles could you please test the revision @bu5hm4n did here to fix the issue?

For the record: I have a svg icon theme.

I think this is fixed by the svg fix you provided. I cannot reproduce this anymore.

Possible way to track it down is to run enlightenment under Xephyr by passing -massif to enlightenment_start and try to reproduce it that way. It should give deeper meaningful trace and associate it with timing information that could lead to an understanding of what is going on. It might be linked to specific engine configuration like texture mapping stuff.

I have been running expedite under massif and only found a leak in the VG part. Nothing that would explain enlightenment leak.

I expected this to be from the cursor idle animations, but I created a test app to simulate it and after an hour or so there were no leaks.

Resolut by D9900

I haven't touched it, so no idea what it may be. Also, EDI uses textgrid I think, not textblock, so it's nothing I even ever touched before.

This sounds like a text regression.

cool. i saw those :) let's call this done for now.

Regarding other findings

Right now am concentrating on reducing number of memory allocation and string parsing during startup time as well as memory consumption ( unnecessary ) . Will tag you when I raise a patch or bug against it.

@raster ,
I saw your patch already landed in master. Awesome :)

yeah. actually found bug #2 in that patch. i still have one of my unlocked funcs still lock. forgot to remove them... now down to .... 28 locks to start elm test. so... update. locally with an updated patch... 615604 -> 28 lock+unlock cycles. i think... that will be good enough eh? :) even if a read lock is 3x as expensive... we do it 0.004% as much as before, and still get the write contention improvements. :) i call this a win.

cool. so i guessed what you wanted. btw that patch has a small bug in it. find it :) (i already have and fixed it locally). it won't affect running things and testing performance though.

In T8121#139875, @raster wrote:

i thought my git commit log explained that - it sped things up when there was contention ? can you provide much more detailed benchmarks and tools to show all the cases? like simple usage, more complex usage in single threads, multiple threads (a few of them, many of them) etc. ?

if you mean to have an unlocked version of eet_dictionary api's and then manually take read lock on the dict when we do an eet_read... of some sort so it's only taking the lock once per eet_read... ?

In T8121#139887, @raster wrote:

btw... that should actually be faster than the original spinlock before rwlock as it's even less lock+unlocks. as it's a rwlock multiple readers will not block each-other unlike spinlocks too. only a writer will end up blocking others and that path i have left as-is.

In T8121#139886, @raster wrote:

so do you mean something like: P319

(patch against efl) ? (locked vs unlocked paths to reduce lock/unlocks during decode to a minimum set).

btw... that should actually be faster than the original spinlock before rwlock as it's even less lock+unlocks. as it's a rwlock multiple readers will not block each-other unlike spinlocks too. only a writer will end up blocking others and that path i have left as-is.

so do you mean something like: P319

nah - just a performance thing and it's not a huge one... it's only in some code paths. so not showstopper

@segfaultxavi can you please check D9391

Is fixed.

False alarm, dunno what it was.

Yes, that fixed it, thanks.

@escwyp Can you recheck with current master? ebf39e9fd7ba054f49031f7f4162ced8c63b1d22 should have fixed this.