On Oct 8, 2014, at 10:48 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Tue, Oct 7, 2014 at 6:57 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > >> On Mon, Oct 6, 2014 at 8:27 PM, Cameron Zwarich <zwar...@mozilla.com> >> wrote: >>>> So you’re suggesting Servo could get away with UTF-8 in the DOM? I >> hadn’t considered it. I remove my proposal at the start of this thread, I’d >> like us to try this instead. >>> >>> UTF-8 strings will mean that we will have to copy all non-7-bit ASCII >> strings between the DOM and JS. >> >> Not if JS stores strings as WTF-8. I think it would be tragic not to >> bother to try to make the JS engine use WTF-8 when having the >> opportunity to fix things and thereby miss the opportunity to use >> UTF-8 in the DOM in Servo. UTF-16 is such a mistake. >> > > I agree. There's an opportunity here to improve speed and memory usage > while simplifying the overall engine design by having the whole engine use > *TF-8 except for JS. We believe we can fix JS performance with a bounded > amount of work, and we don't even have to do that work up-front since > copying strings between JS and DOM is a viable solution for now. I would be in favor of using UTF-8 in the DOM in Servo if SpiderMonkey would be willing to accept the maintenance burden of having a UTF-8 (WTF-8?) code path that is not used by Gecko. This doesn’t mean that they would have to implement it, just that if an implementation was produced they would be okay with maintaining it. I don’t think it would be good to choose UTF-8 in the DOM in Servo if SpiderMonkey is realistically never going to support it without copies. Cameron _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
