On Fri, May 12, 2017 at 4:28 AM, Kan-Ru Chen <kc...@mozilla.com> wrote: > On Thu, May 11, 2017, at 01:43 PM, Henri Sivonen wrote: >> In Firefox 43, I rewrote our Big5 support and, among other things, I >> optimized the *encoder* for footprint rather than speed on the theory >> that users won't notice anyway since the encoder run is followed by a >> dominating wait for the network when submitting a form. >> >> Since then, I've learned that the relative slowness of the Big5 >> encoder is greater than I had anticipated. Still, I haven't seen >> anyone complaining, but I don't know if anyone who finds it too slow >> knows how to attribute the complaint. >> >> I'd like to hear from someone who uses a Web site/app that involves >> submitting a textarea of Traditional Chinese text in Big5 if the form >> submission performance seems normal (doesn't feel particularly slow) >> on low-performance hardware, like an Android phone. (In the phone >> case, I mean the amount of text you'd feel OK to input on a phone at >> one time.) >> >> If UTF-8 is so widely deployed that no one in the Taipei office needs >> to submit forms in Big5 anymore, that would be good to know, too. > > I don't feel that I see a lot of Big5 websites out there. It's hard for > me to even find one to test.
Thank you. I guess it doesn't really matter whether Big5 form submission feels slow or not if it's something that people very rarely experience. >> Context: >> I need to decide if I should make Big5 encode faster or if I should >> trade off speed for smaller footprint for the legacy Simplified >> Chinese and Japanese *encoders*, too. > > I think Shift_JIS are still widely used. But this is just my experience > and guessing. If we really want to know the real word usage we should > collect data. Is there some telemetry probe for this already? If Big5 form submission is so rarely used that its performance doesn't matter, we can't then extrapolate the lack of complaints to inform the implementation Japanese or Simplified Chinese legacy encodings. Keeping the implementation approach asymmetry between Big5 on one hand and legacy Japanese and legacy Simplified Chinese encodings on the other hand seems like a valid approach in the case of a large disparity in usage today. There aren't telemetry probes for "this" regardless of what "this" you meant. To my knowledge, there's no telemetry probe for counting form submission encodings and there is no telemetry probe measuring form submission round trip time by encoding. Telemetry analysis in this area would have to be scoped by locale (e.g. analysis of relative frequency of Big5 and UTF-8 form submissions scoped to the zh-TW locale) to be meaningful, and, from experience, such analyses are annoying to carry out, because they need manual privileged access to telemetry data. Locale-scoped views aren't available on the telemetry dashboards, because some locales have so few users that scoping by locale would narrow the population so much that the data could be potentially too identifiable. It would be nice if locale-scoped views were available for locales whose telemetry-enabled instances are more numerous than some threshold. (Each of zh-TW, zh-CN and ja-JP surely has enough users, at least on the release channel, for aggregate data views not to be too identifiable.) Additionally, I don't really know what would be a good way to place a probe in our code to measure form submission round trip time (what the user perceives) rather than the encode step only. (It's already obvious that the encode step itself would show a disparity by a massive factor between UTF-8 and Big5.) (I don't think we need telemetry to believe that Shift_JIS and gbk form submissions still happen routinely.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
