There's also a pre-processor constant that we define in Valgrind/ASAN/etc. builds that you can check in order to free more stuff than you otherwise would. But I can't for the life of me remember what it's called :(
Nick On Sat, May 20, 2017 at 5:09 AM, Jeff Muizelaar <jmuizel...@mozilla.com> wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
