Memory

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The next feature release of phpBB 3 will be 3.3/Proteus.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.1. If you need support for phpBB 3.1 please visit the 3.1.x Support Forum on phpbb.com.

If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
User avatar
keith10456
Registered User
Posts: 523
Joined: Sat Apr 22, 2006 10:29 pm
Contact:

Re: Memory

Post by keith10456 » Wed Mar 20, 2013 10:23 pm

Jacob wrote:
brunoais wrote:If I go forward with the TextFormatter this value will increase by a significant amount...Prepare a nice increase with phpBB 3.2, in that case.
In that case I won't be using phpBB 3.2. I'm not sure that I'll upgrade to 3.1, even.
If the extension system is not going to be/can't be used for memory consuming features, and these will be included in the core instead, the usefulness of the extension system will be really limited. For me, anyway.
A bit premature... If I were you I would wait until at least the Beta is released on 3.1, let alone 3.2.

User avatar
EXreaction
Registered User
Posts: 1555
Joined: Sat Sep 10, 2005 2:15 am

Re: Memory

Post by EXreaction » Wed Mar 20, 2013 11:43 pm

When 3.0.0 was released, memory prices were 5x their current prices, so it's probably safe to assume the average server built today has 5x the memory as it did when 3.0.0 was released.

Memory usage in 3.1.0 might have increased 30% over 3.0.0 according to the tests on the previous page, that's roughly 1/15 of the memory increase in that time.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: Memory

Post by Oleg » Thu Mar 21, 2013 3:38 am

3.1 uses more memory for php code than 3.0. This is partially due to using more third-party libraries (which do more than we need, therefore at least burning memory if not cpu time that 3.0 did not) and partially because "modern php" moves toward java in terms of the amount of boilerplate code being used. Within 3.1 itself the code is more verbose than it was in 3.0.

The upside of these changes is stuff like extension system. While it is possible to implement the new features in 3.0 style, most people are not that masochistic. This is like debating using C vs java/python.

Ultimately, additional memory consumption by the code is not significant. Even going from 3 mb to 7 mb for code when the minimum usable memory limit is 32 mb due to unicode tables, post data and file uploads is not that big of a deal.

That said, patches improving the situation are welcome. And 3.1 does a huge amount of redundant work on each page load with debug enabled, which besides burning outrageous amounts of cpu also uses memory.

User avatar
bantu
3.0 Release Manager
3.0 Release Manager
Posts: 557
Joined: Thu Sep 07, 2006 11:22 am
Location: Karlsruhe, Germany
Contact:

Re: Memory

Post by bantu » Thu Mar 21, 2013 4:17 pm

Oleg wrote:Ultimately, additional memory consumption by the code is not significant. Even going from 3 mb to 7 mb for code when the minimum usable memory limit is 32 mb due to unicode tables, post data and file uploads is not that big of a deal.
I agree. Most of 3.0.x used to work just fine with a memory limit of 16 MiB, under some circumstances even 12 MiB. There is absolutely nothing wrong with increasing the absolute minimum to 32 MiB as memory in servers increases anyway.

User avatar
JoshyPHP
Registered User
Posts: 358
Joined: Fri Jul 08, 2011 9:43 pm

Re: Memory

Post by JoshyPHP » Fri Nov 29, 2013 5:01 pm

Sorry for bumping an old topic but it's been referenced in phpBB 3.1 load and I need to address the following:
brunoais wrote:If I go forward with the TextFormatter this value will increase by a significant amount...Prepare a nice increase with phpBB 3.2, in that case.
This "TextFormatter" is s9e\TextFormatter, a library that I created a while ago which has a standing RFC that will hopefully get merged in 3.2. It's super cool and it's got tons of features, but most importantly it's quite fast and quite efficient.

I could sing my own praise until an eagle named "Premature Optimization" flies into the room, but instead here are some numbers:

Code: Select all

Parse  plain text with old: 4.16 MiB in 3555 µs
Parse  plain text with new: 4.29 MiB in 3364 µs
Parse  rich  text with old: 4.19 MiB in 3878 µs
Parse  rich  text with new: 4.32 MiB in 3630 µs
Render plain text with old: 2.62 MiB in   81 µs
Render plain text with new: 2.69 MiB in  267 µs
Render rich  text with old: 2.67 MiB in  617 µs
Render rich  text with new: 2.69 MiB in  359 µs
Those numbers were generated with this script off a fresh install of the latest versions of my branch ("new" in the table above) and develop ("old" above.) Both versions were configured for production: non-debug and no dev dependencies. Peak memory usage in MiB followed by time elapsed in microseconds (millionths of a second.) Obviously, the numbers are very close and there's no reason to expect s9e\TextFormatter to use more resources than the legacy routines.

Edit: realized a few days later that I was using Composer with the optimized classmap. Re-ran the same test, got lower numbers. (obviously the classmap takes RAM)

Code: Select all

Parse  plain text with old: 3.99 MiB in 3648 µs
Parse  plain text with new: 4.06 MiB in 3331 µs
Parse  rich  text with old: 4.01 MiB in 3973 µs
Parse  rich  text with new: 4.09 MiB in 3630 µs
Render plain text with old: 2.44 MiB in   81 µs
Render plain text with new: 2.46 MiB in  240 µs
Render rich  text with old: 2.50 MiB in  619 µs
Render rich  text with new: 2.46 MiB in  331 µs

Post Reply