On Tue, Dec 3, 2013 at 10:02 PM, Roan Kattouw roan.katt...@gmail.comwrote:
* The drop occurred because ResourceLoaderLanguageDataModule had a bug
in its mtime computation, causing it to recache all the time; module
storage greatly dampened the impact of that bug.
This is true, and it was a
On 12/08/2013 11:55 PM, Tyler Romeo wrote:
I'm sure this has already been taken into consideration, but keep in mind
that code that is executed using eval() in Javascript is *not* optimized by
the V8 compiler like normal script resources are.
Are you sure this is still the case?
I am somewhat concerned about the implications for JS debugging here.
Debugging JS problems with the live sites is already pretty complicated:
1. debug=true won't reproduce some bugs (usually race condition related)
2. Sometimes old code gets cached with the new cache-busting timestamp (due
to a
On Mon, Dec 9, 2013 at 2:58 PM, Ryan Kaldari rkald...@wikimedia.org wrote:
I am somewhat concerned about the implications for JS debugging here.
Debugging JS problems with the live sites is already pretty complicated:
1. debug=true won't reproduce some bugs (usually race condition related)
On Mon, Dec 9, 2013 at 5:25 PM, Ori Livneh o...@wikimedia.org wrote:
On Mon, Dec 9, 2013 at 2:58 PM, Ryan Kaldari rkald...@wikimedia.orgwrote:
I am somewhat concerned about the implications for JS debugging here.
Debugging JS problems with the live sites is already pretty complicated:
1.
On Mon, Dec 9, 2013 at 2:15 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
Are you sure this is still the case?
https://code.google.com/p/v8/issues/detail?id=2315 seems to suggest that
this was fixed in V8 last year.
Not sure if it's related, but looking at the bleeding edge compiler.cc code
On Mon, Dec 9, 2013 at 8:33 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Mon, Dec 9, 2013 at 2:15 PM, Gabriel Wicke gwi...@wikimedia.org
wrote:
Are you sure this is still the case?
https://code.google.com/p/v8/issues/detail?id=2315 seems to suggest that
this was fixed in V8 last year.
On 12/09/2013 08:33 PM, Tyler Romeo wrote:
On Mon, Dec 9, 2013 at 2:15 PM, Gabriel Wicke gwi...@wikimedia.org wrote:
Are you sure this is still the case?
https://code.google.com/p/v8/issues/detail?id=2315 seems to suggest that
this was fixed in V8 last year.
Not sure if it's related, but
I'm sure this has already been taken into consideration, but keep in mind
that code that is executed using eval() in Javascript is *not* optimized by
the V8 compiler like normal script resources are.
Considering our scripts do not perform much intensive work AFAIK, it should
not be an issue, but
On Tue, Nov 5, 2013 at 4:56 PM, Ori Livneh o...@wikimedia.org wrote:
On Mon, Nov 4, 2013 at 4:50 AM, Mark A. Hershberger m...@nichework.com
wrote:
Hrm... I should probably go ask them about that. But I'm curious about
your perspective and to see if we have any information on the bandwidth
On 03.12.2013, 12:30 Ori wrote:
The size of the effect is
substantially smaller on mobile, for some reason, which is surprising.
Mobile simply has fewer modules;)
--
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
On Tue, Dec 03, 2013 at 12:30:00AM -0800, Ori Livneh wrote:
We ran a controlled test and found that module storage reduced page load
times by 156 ms, on average. Aaron has some data available at
https://meta.wikimedia.org/wiki/Research:Module_storage_performance, but
we still need to write
To be fair last time I checked there was a lot of dead JS and CSS
(e.g. [1]) that should not be loaded in the first place for every
page. Reducing this should make things even smoother for users.
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
On Tue, Dec 3, 2013 at 7:04 AM, Faidon
On Tue, Dec 3, 2013 at 12:30 AM, Ori Livneh o...@wikimedia.org wrote:
We'll gradually enable module storage on all Wikimedia wikis over the
course of the next week or two.
Ori deployed this to the live site earlier today :) . For reference,
the original post about module storage is archived at
That is a statement, not an explanation.
John
On Thu, Nov 7, 2013 at 4:05 PM, Jon Robson jdlrob...@gmail.com wrote:
From personal experience don't touch cache manifests with a barge pole...
Bear in mind the majority of browsers provide at least 5mb of local storage
and we are talking about
That is a statement, not an explanation.
Please provide a valid explanation why you want to do this.
John
On Thu, Nov 7, 2013 at 9:35 AM, Daniel Friesen
dan...@nadir-seen-fire.com wrote:
Cache manifests are extremely inflexible. The HTTP caching we already
have is more flexible than cache
I'm not interested in writing an entire explanation for you on how cache
manifests work and their faults when you could simply do a web search
for one of the many existing tutorials.
The issues with using cache manifests to try and do this should be
perfectly understandable once someone
Le 08/11/13 10:33, Daniel Friesen a écrit :
I'm not interested in writing an entire explanation for you on how cache
manifests work and their faults when you could simply do a web search
for one of the many existing tutorials.
If you could explain to the newbie there like me what a cache
On Fri, Nov 8, 2013 at 9:45 AM, Antoine Musso hashar+...@free.fr wrote:
So what is a cache manifest? :D
tl;dr - Cache manifests are made for offline web apps, and Wikipedia is not
an offline web app.
Cache manifests are a new HTML5 feature that is specifically made for
single page (or, at the
.. 3) it is a nightmare
http://alistapart.com/article/application-cache-is-a-douchebag is a good
read to anyone who is curious to the why.
On 8 Nov 2013 07:06, Tyler Romeo tylerro...@gmail.com wrote:
On Fri, Nov 8, 2013 at 9:45 AM, Antoine Musso hashar+...@free.fr wrote:
So what is a cache
On Fri, Nov 8, 2013 at 11:33 AM, Jon Robson jdlrob...@gmail.com wrote:
.. 3) it is a nightmare
http://alistapart.com/article/application-cache-is-a-douchebag is a good
read to anyone who is curious to the why.
I wouldn't go so far to say it is a nightmare. The article you linked
blows things
I've used cache manifests for offline applications. It works reasonably
well in that situation. So I wouldn't dismiss it entirely for all purposes.
But it's not the right solution here.
--scott
___
Wikitech-l mailing list
Can you explain why you use LocalStorage for this? It seems to me like
this is the wrong solution and you should use cache manifests instead.
LocalStorage is a quite limited area for _data_ storage and it will
create problems if we start wasting that space for _code_ storage.
John
On Mon, Nov 4,
Cache manifests are extremely inflexible. The HTTP caching we already
have is more flexible than cache manifests. So cache manifests won't
help make any improvements.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2013-11-07 12:19 AM, John Erling Blad wrote:
Can you
From personal experience don't touch cache manifests with a barge pole...
Bear in mind the majority of browsers provide at least 5mb of local storage
and we are talking about caching a few kB at most of minified JavaScript
On 7 Nov 2013 00:35, Daniel Friesen dan...@nadir-seen-fire.com wrote:
What should I be aware of as a developer? That is, if I'm running a local
MW and hacking on a resources (an extension / JavaScript / etc) will things
Just Work? Or should I take active steps to disable Module Storage so that
I don't inadvertently run the 'old' version of something I'm hacking
On Thu, Nov 7, 2013 at 8:05 AM, Jon Robson jdlrob...@gmail.com wrote:
From personal experience don't touch cache manifests with a barge pole...
Bear in mind the majority of browsers provide at least 5mb of local storage
and we are talking about caching a few kB at most of minified
I'm not sure why shift reloading would make the cache grow since the
same page should load exactly the same modules - if that's not the
case that points at a bug somewhere.
That said since there are a potentially infinite amount of
modules/gadgets, many of which are rarely used that can be loaded
On Thu, Nov 7, 2013 at 12:22 PM, Jon Robson jdlrob...@gmail.com wrote:
I'm not sure why shift reloading would make the cache grow since the
same page should load exactly the same modules - if that's not the
case that points at a bug somewhere.
Seems like a bug, to me.
That said since
We may want to make some considerations for multiple wiki on the same
origin though.
For example a wiki that uses paths for multiple languages:
wiki.example.com/en/Foo
wiki.example.com/fr/Foo
wiki.example.com/de/Foo
...
On a setup like this all the wikis will share the same localStorage
origin
On Sun, Nov 3, 2013 at 5:27 PM, Ori Livneh o...@wikimedia.org wrote:
How can I test it?
--
Glad you asked! Module storage is enabled by default on the beta
cluster, and on test test2 wikis.
It's also enabled on MediaWiki.org now, the last such wiki before
doing performance
I found a usability problem with some versions of the webkit/chrome
inspector for localStorage due to this, it is being tracked here:
https://bugs.webkit.org/show_bug.cgi?id=123750
On Mon, Nov 4, 2013 at 7:20 PM, Isarra Yos zhoris...@gmail.com wrote:
On 04/11/13 15:31, Mark A. Hershberger
On Mon, Nov 4, 2013 at 4:50 AM, Mark A. Hershberger m...@nichework.com wrote:
Hrm... I should probably go ask them about that. But I'm curious about
your perspective and to see if we have any information on the bandwidth
available to various users.
There is some, but not enough for us to know
On Nov 4, 2013 2:28 AM, Ori Livneh o...@wikimedia.org wrote:
The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will
inaugurate the era of ResourceLoader module storage -- an era which
will be marked by terrifying and hilarious new bugs, intermittent
client-side failures, and generally
On 11/03/2013 08:27 PM, Ori Livneh wrote:
* Module storage is enabled only if the underlying browser supports
localStorage (~89% of browsers in use, according to
http://caniuse.com/#feat=namevalue-storage). Users with older
browsers will not see a benefit, but they will not suffer a penalty
On Mon, Nov 4, 2013 at 1:50 PM, Mark A. Hershberger m...@nichework.comwrote:
Ori, Thank you for this fun-to-read introduction to Module Storage.
+1
Željko
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 04.11.2013, 16:50 Mark wrote:
Ori, Thank you for this fun-to-read introduction to Module Storage.
I wonder if this will have any affect on low bandwidth users. It seems
like this would help if someone had only a 2G/GPRS connection, but do a
lower percentage of those users have browsers
On 11/04/2013 10:10 AM, Max Semenik wrote:
Most of our mobile traffic is genrated by iOS and Android - both of
which support LocalStorage, so it will work for them too.
People using 2G/GPRS are not necessarily using a mobile device. I've
heard from at least one user (hence
I'm looking forward to seeing how this plays out. The only downside I
can so far see is that the amount of browser storage available varies
drastically [1] and I wonder whether this will cause upsets for those
browsers with extremely strict limits.
I've also been toying with the idea of using
On Mon, Nov 4, 2013 at 11:13 AM, Jon Robson jdlrob...@gmail.com wrote:
I'm looking forward to seeing how this plays out. The only downside I
can so far see is that the amount of browser storage available varies
drastically [1] and I wonder whether this will cause upsets for those
browsers with
On 04/11/13 15:31, Mark A. Hershberger wrote:
On 11/04/2013 10:10 AM, Max Semenik wrote:
Most of our mobile traffic is genrated by iOS and Android - both of
which support LocalStorage, so it will work for them too.
People using 2G/GPRS are not necessarily using a mobile device. I've
heard
The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will
inaugurate the era of ResourceLoader module storage -- an era which
will be marked by terrifying and hilarious new bugs, intermittent
client-side failures, and generally inexcusable disruptions to user
experience. Sounds exciting? Read
MediaWiki: Manually fixing broken browser functionality since 2012.
Also I do wonder how useful this actually is. Does site JavaScript really
change that often? I suppose we'll find out after testing.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
43 matches
Mail list logo
