This is getting a little out of hand? People are going to spend more time talking about the potential for minification errors or sub optimisation cost criteria then we will ever actually be running into real minification errors or any real readability issue. Reasonable efforts are being made to make the non-minified versions easily accessible. We can add additional comment to every outputted file that says request me with ?debug=true to get the source code version, add a user preference, add a cookie, and a view non-minfied source link to the bottom every page...
But try to keep in mind the whole point of minification is identical program execution while minimising the file size! If we are to optimise with random adjustments for "readability" we are optimising in two opposite directions, and every enhacment in the direction of optimized pacakge code delivery could potentially go against the 'readability' optimisation. We are already commited to supporting two modes one that optimized readability with raw source code delivery and one that is optimised for small packaged delivery. No sense in setting readability as criteria for the packaged mode since the 'readability' mode will always do 'readability' better. --michael On 10/01/2010 12:38 AM, Trevor Parscal wrote: > I was hardly making a case for how amazingly expensive it was. I was > running some basic calculations that seemed to support your concept of > "fairly cheap", but chose to mention that it's still "not free". > > - Trevor > > On 9/30/10 9:30 PM, Tim Starling wrote: >> On 01/10/10 04:35, Trevor Parscal wrote: >>> OK, now I've calculated it... >>> >>> On a normal page view with the Vector skin and the Vector extension >>> turned on there's a 2KB difference. On an edit page with the Vector skin >>> and Vector and WikiEditor extensions there's a 4KB difference. >>> >>> While adding 2KB to a request for a person in a remote corner of the >>> world on a 56k modem will only add about 0.3 seconds to the download, >>> sending 2,048 extra bytes to 350 million people each month increases our >>> bandwidth by about 668 gigabytes a month. >> We don't pay by volume (GB per month), we pay by bandwidth (megabits >> per second at the 95th percentile). They should be roughly >> proportional to each other, but to calculate a cost we have to convert >> that 668GB figure to a percentage of total volume. >> >> I took this graph: >> >> http://www.nedworks.org/~mark/reqstats/trafficstats-monthly.png >> >> And I used the GIMP histogram tool to integrate the outgoing part for >> 30 days between week 34 and week 37. The result was 31,824 pixels of >> blue and 20,301 pixels of green, which I figure is about 2113 >> TB/month. So on your figure, the cost of adding line breaks would be >> about 0.03% of whatever the bandwidth bill for that month is. I don't >> have that number to hand, but I suspect 0.03% of it is not going to be >> very much. For 2009-2010 there was a budget of about $1M for "internet >> hosting", of which bandwidth is a part, and 0.03% of that entire >> budget category is only $25 per month. >> >> I think your 668GB figure is too low, because current uniques is more >> like 390M per month, and because some unique visitors will request the >> JS more than once. You can double it if you think it would help you >> make your case. >> >>> I don't know what that kind of >>> bandwidth costs the foundation, but it's not free. >> Developer time is not free either. >> >> -- Tim Starling >> >> >> _______________________________________________ >> Wikitech-l mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
