We use functions like cairo_debug_reset_static_data() on shutdown to handle cases like this.
-Jeff On Fri, May 19, 2017 at 1:44 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > On Tue, May 16, 2017 at 7:03 AM, Tim Guan-tin Chien > <timdr...@mozilla.com> wrote: >> According to Alexa top 100 Taiwan sites and quick spot checks, I can only >> see the following two sites encoded in Big5: >> >> http://www.ruten.com.tw/ >> https://www.momoshop.com.tw/ >> >> Both are shopping sites (eBay-like and Amazon-like) so you get the idea how >> forms are used there. > > Thank you. It seems to me that encoder performance doesn't really > matter for sites like these, since the number of characters one would > enter in the search field at a time is very small. > >> Mike reminded me to check the Tax filing website: http://www.tax.nat.gov.tw/ >> .Yes, it's unfortunately also in Big5. > > I guess I'm not going to try filing taxes there for testing. :-) > > - - > > One option I've been thinking about is computing an encode > acceleration table for JIS X 0208 on the first attempt to encode a CJK > Unified Ideograph in any of Shift_JIS, EUC-JP or ISO-2022-JP, for GBK > on the first attempt to encode a CJK Unified Ideograph in either GBK > or gb18030, and for Big5 on the first attempt to encode a CJK Unified > Ideograph in Big5. > > Each of the three tables would then remain allocated through to the > termination of the process. > > This would have the advantage of not bloating our binary footprint > with data that can be computed from other data in the binary while > still making legacy Chinese and Japanese encode fast without a setup > cost for each encoder instance. > > The downsides would be that the memory for the tables wouldn't be > reclaimed if the tables aren't needed anymore (the browser can't > predict the future) and executions where any of the tables has been > created wouldn't be valgrind-clean. Also, in the multi-process world, > the tables would be recomputed per-process. OTOH, if we shut down > rendered processes from time to time, it would work as a coarse > mechanism to reclaim the memory is case Japanese or Chinese legacy > encode is a relatively isolated event in the user's browsing pattern. > > Creating a mechanism for the encoding library to become aware of > application shutdown just in order to be valgrind-clean would be > messy, though. (Currently, we have shutdown bugs where uconv gets used > after we've told it can shut down. I'd really want to avoid > re-introducing that class of bugs with encoding_rs.) > > Is it OK to create allocations that are intentionally never freed > (i.e. process termination is what "frees" them)? Is valgrind's message > suppression mechanism granular enough to suppress three allocations > from a particular Rust crate statically linked into libxul? > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
