I believe there's some serious issue about Types memory usage. I am using latest Types versione (1.5.4) on a site that has 5000+ pages. When I enable the Types plugin the memory allocated in the admin edit pages list jumps from ~180 MB to ~256 MB. This happens even if there are NO Custom Post Types / Custom Fields / Custom Taxonomies activated in Types. It's just Types being enabled that increases the memory usage so much. In some cases this triggered "out of memory" errors resulting in blank admin pages, so I had to increase the PHP memory limit, which I wouldn't have to do.
The issue surely depends on the total number of posts in the site, since in other sites with far less posts the memory gap is just a few MB. Anyway I think this issue should be addressed somehow by the dev team. I also tried other alternative plugins that provide features similar to Types and they do not have such a problem.
Thanks for your attention.
Dear Francesco,
Are you able to send me a database dump so we can do some testing and find out where the memory goes? If so I can write you a private email to send it to me.
Regards,
Caridad
Hello,
I just sent you an email with a download link. Thank you.
Dear Francesco,
With only the Debug Bar plugin enabled, no Types, its already giving me memory problems:
Allowed memory size of 268435456 bytes exhausted in wp-includes/cache.php on line 591
I will pass this information to our developers to look into it.
Thanks for catching this,
Regards
Caridad
Dear Francesco,
I get the impression that its the debug bar plugin keeping a lot of debug information, but let me confirm this end with you. I have asked the developer for further feedback.
Regards
Caridad
Hi there, I keep getting notifications that this support topic will be closed for inactivity, but I've been waiting for a relevant feedback on this issue for 2 months. It looks like there's no interest from the Toolset dev team to improve the performance of the plugin on very large sites.
I eventually had to abandon the Types plugin for this project and use a concurrent similar plugin, which runs flawlessly, as I could not wait any more.
Dear Francesco,
Our developers reached the conclusion that it was Debug Bar taking up all the extra memory.
This is all the feedback I had from the developers. Let me ask for further feedback.
Regards
Caridad
PS: the automatic notifications go out after 2 weeks of inactivity, so this thread isn't forgotten.
Dear Frencesco,
Meanwhile, can you see if you are getting the same problems without the Debug Bar plugin enabled?
Thanks
Caridad
Dear Francesco,
I got some feedback from our developers, I will copy and paste here as is:
We reckon Types is not a problem here ... let me explain.
We have two slow queries on "pages" screen.
First is depend on WordPress "sort order" for pages witch use field "menu_order", and mysql must always sort this.
solution:
ALTER TABLE `wp_posts` ADD INDEX ( `menu_order` )
Adding pages is a little bit slower, but first "slow query" is gone.
Second query is query:
"SELECT post_id, meta_key, meta_value etc. etc." witch gets ALL postmeta of published pages, that's actually 39044 records.
---
Memory:
WP consumes a lot of memory because "WP_Posts_List_Table->prepare_items" get ALL data of all pages ...
Maximum consumes memory on my local machine is about 180 MB which will end wrong.
I'm afraid we can not help with this issue.
Regards,
Caridad
Hi there,
I appreciate that you are investigating on this issue, but I think you're not moving in the right direction.
Now I made a dev copy of this site in order to conduct a few more tests, because the live site is now in production.
1. I never mentioned Debug Bar plugin. I didn't use it on this particular site, so any conclusion based on the assumption of Debug Bar usage is simply out of place. For memory usage measurement I used either custom code or a lightweight plugin like TPC! Memory usage or WP-Memory-Usage.
2. Adding an index on a db table has no effect on PHP side memory usage. It may have impact on query execution time, but this was not the main problem. By the way, even after adding the index on menu_order field, there's no visible speed-up (human perception). But I repeat, the problem was not the load time, but the memory usage.
3. I didn't have the time to perform a detailed debug of this, but I believe that the query that consumes a lot of memory is triggered by the Types plugin.
I can confirm that even with the latest Types version (1.5.6) there's an huge increase on memory usage, just for Types activation, even with no CPT or custom fields defined.
The memory usage for the admin page list screen is actually the following:
Types disabled: 284 MB
Types enabled: 382 MB
When using another plugin with features similar to Types, there's not such an high memory usage increment. It's ~+20MB vs ~+100MB actually.
Dear Francesco,
Thanks for the extra information, I will pass this on to the development team and they should get back to you shortly.
Regards
Caridad
Dear Francesco,
Our developers are looking into this further, but meanwhile I got a quick reply:
> Quick (not good) solution:
> comment line 32 from
> types/embedded/classes/loader.php
Can you check this and get back to us?
Regards
Caridad