$wrapper->reset() should unset $wrapper->cache

But clear() only gets called when something is changed? So it won't be cleared automatically? Perhaps we should just add a public reset() method for clearing caches?

Afaik, the problem is 5.2 only. So upgrading to 5.3 should solve it too.

+++ b/includes/entity.wrapper.incundefined
@@ -167,6 +167,10 @@ abstract class EntityMetadataWrapper {
+    // Clear the cache, so we won't have any child object still ¶
+    // referenced, so later PHP's garbage collector will destruct the ¶

Patch works... It's up to fago to decide whether we want to implement it like this. However, if we choose to use this patch we should remove the trailing whitespaces in the first two lines of the comment :).

Hm, if we do that I don't think the cache would help a lot. Anyway, I've been thinking whether it's necessary to have that kind of cache at all. Maybe we should do some benchmarks on it, e.g. with using some Rules and other common access patterns?

Reasons for removing the cache:

• Less complexity.
• No circular dependencies, gc++.
• No possible weird issues when using language() which adds a state to the wrapper object combined with the cache.

This thread is quite old, but I'm interested if there was any discussion regarding this.

I'm experiencing this problem where using entity_metadata_wrapper on around 200000 items is using too much memory. I had to break down into smaller pieces by separate process in order to keep memory in check.

I will try the patch, but I would really appreciate if someone could point me to an update on this. Using version 7.x-1.6 on my site.

Regards,

public reset() would be nice. I noticed after a commerce_order save that the cache was stale on the EMW.

data was correct but cache was stale on the number of commerce_line_items field items on the order.

Yup adding a reset() and clearing the cache fixes my issue.

I just put the patch up to test something out but I'm a big +1 to #5

Going to RTBC this as I ran into similar caching issues with EMW. This was in PHP 5.6, so not just a problem in 5.2.

If there are no plans to remove the cache as mentioned in #5, this patch at least makes it possible to manually clear the cache when you're having problems.

Yep, adding a public reset is fine, however this patch also adds the reset we do not want / can do without performance benchmarks. So setting to needs work.

FWIW, I still desire this feature.

Here's the patch with the modification recommended by fago.

That's a bit of progress on the issue, I'll take it.