Fomafix added a comment.
Exactly. Is https://gerrit.wikimedia.org/r/331208 the right step into this direction? What are the next steps?TASK DETAILhttps://phabricator.wikimedia.org/T43103EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: FomafixCc: Rical,
daniel added a comment.
@Fomafix LanguageCode is useful to identify a language, but we also need lightweight access to some properties of the language: most importantly, whether it's ltr or rtl; but also the date and numer format, or the language name in different languages. This information
Fomafix added a comment.
With https://gerrit.wikimedia.org/r/331208 it is suggested to introduce a new PHP class LanguageCode. This class can also take some of the code from the class Language. Maybe the class LanguageCode can be a lightweight part of the class Language with a better performance.
Nikerabbit added a comment.
So I thought as well, but I haven't found any proof that it is still heavy.
TASK DETAIL
https://phabricator.wikimedia.org/T43103
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Nikerabbit
Cc: adrianheine, gerritbot,
Fomafix added a comment.
I think the Language object is still very heavy. Maybe a new lightweight
object just for the language code would be an improvement.
TASK DETAIL
https://phabricator.wikimedia.org/T43103
EMAIL PREFERENCES
Fomafix added a comment.
In https://phabricator.wikimedia.org/T43103#1884553, @Nikerabbit wrote:
> What version of MediaWiki? What storage backend? I no longer see high memory
> consumption.
- MediaWiki from the current git master version with SQLite.
- The 1.5 GB footprint is after deleted
Nikerabbit added a comment.
Ok, regenerating the localisation cache is heavy on memory, but that is not why
this bug was filed. I actually think this bug is fixed and LU recache could be
it's own thing.
TASK DETAIL
https://phabricator.wikimedia.org/T43103
EMAIL PREFERENCES
gerritbot added a subscriber: gerritbot.
gerritbot added a comment.
Change 259509 had a related patch set uploaded (by Nikerabbit):
LocalisationCache: stop unconditional preloading for all languages
https://gerrit.wikimedia.org/r/259509
TASK DETAIL
https://phabricator.wikimedia.org/T43103
Fomafix added a comment.
On my system the command
> time echo 'foreach ( Language::fetchLanguageNames() as $l => $name ) { print
> Language::factory( $l )->getHtmlCode(); }' | php maintenance/eval.php
consumes with cleared file cache:
real2m54.465s
user2m14.753s
sys
Nikerabbit added a comment.
In https://phabricator.wikimedia.org/T43103#1884443, @Fomafix wrote:
> The process consumes up to 1.5 GB of memory.
What version of MediaWiki? What storage backend? I no longer see high memory
consumption.
TASK DETAIL
https://phabricator.wikimedia.org/T43103
gerritbot added a comment.
Change 259509 abandoned by Nikerabbit:
LocalisationCache: stop unconditional preloading for all languages
https://gerrit.wikimedia.org/r/259509
TASK DETAIL
https://phabricator.wikimedia.org/T43103
EMAIL PREFERENCES
Jarekt added a subscriber: Jarekt.
Jarekt added a comment.
There was a talk of rewriting Commons template:Dir
(https://commons.wikimedia.org/wiki/Template:Dir ), which is the most
transcluded template on Commons to use isRTL LUA function, as to keep things
in synch. Template:Dir has
Nikerabbit added a comment.
Sample test case for eval.php:
ini_set( 'memory_limit', '100M' );
$langs = Language::fetchLanguageNames();
foreach ( $langs as $l = $name ) { Language::factory( $l ); }
Fatal error: Allowed memory size of 104857600 bytes exhausted (tried to
allocate 4666 bytes)
13 matches
Mail list logo
