If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

compile in the fast mapping tables rather than generating them at runtime

NEW
Assigned to

Status

()

Core
Internationalization
8 years ago
3 years ago

People

(Reporter: dbaron, Assigned: dbaron)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 2 obsolete attachments)

(Assignee)

Description

8 years ago
One of the performance costs of bug 530328 is to regenerate the fast mapping table every time we instantiate an ISO-8859-* decoder rather than just doing it once.

This patch generates the fast mapping tables as static arrays in the source code so that they do not have to be generated at runtime at all.  (And no mutex is needed to guard their initialization.)  This does increase the amount of static data in the binary a bit, though.

It looks like there are 59 such tables in the tree, at 512 bytes each.  (3 of them are generated from cp1252, though, so we could trim a few.)
(Assignee)

Comment 1

8 years ago
Created attachment 413834 [details] [diff] [review]
patch 1: code to generate static fast mapping tables (*.fut) from existing (*.ut) files

I didn't go out of my way to make this non-portable, but I didn't test that it worked anywhere other than my machine.  It's sort of a one-time thing, but it's worth checking in in case we ever want to change these files.  (Not that we have the tool that generated the *.ut files...)

I don't claim it's pretty either.  But it worked.
(Assignee)

Comment 2

8 years ago
Created attachment 413835 [details] [diff] [review]
patch 2: the *.fut files generated by patch 1
(Assignee)

Comment 3

8 years ago
Created attachment 413836 [details] [diff] [review]
patch 3: change nsOneByteDecoderSupport to expect the fast mapping table as a parameter
(Assignee)

Comment 4

8 years ago
Created attachment 413837 [details] [diff] [review]
patch 4: change users of nsOneByteDecoderSupport (autogenerated)

This was autogenerated using the command contained in the commit message inside the patch.
(Assignee)

Comment 5

8 years ago
Created attachment 413839 [details] [diff] [review]
patch 3: change nsOneByteDecoderSupport to expect the fast mapping table as a parameter
Attachment #413836 - Attachment is obsolete: true
(Assignee)

Comment 6

8 years ago
Created attachment 413840 [details] [diff] [review]
patch 4: change users of nsOneByteDecoderSupport (autogenerated)
Attachment #413837 - Attachment is obsolete: true
(In reply to comment #1)
> (Not that we
> have the tool that generated the *.ut files...)

That would be http://mxr.mozilla.org/seamonkey/source/intl/uconv/tools/umaptable.c

I have a patch in my tree for bug 473792. At the time it didn't seem worth pursuing, but (mutatis mutandis) it would reduce the impact of this on the size of static data.
(Assignee)

Comment 8

3 years ago
I think this is worth finishing, especially given that with e10s there's more of a memory advantage to having constant data in the libraries rather than generated at runtime.
(Assignee)

Comment 9

3 years ago
(Really, all the patches are still fine (in my local copies) except patch 1, since the build system doesn't work that way anymore... and the question is perhaps whether the data need to be regenerated.)

https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/bbba4da514a4/genfasttable
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/bbba4da514a4/fast-ut-files
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/bbba4da514a4/one-byte-decoder-support-fast-table
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/bbba4da514a4/pass-fast-mapping-tables
You need to log in before you can comment on or make changes to this bug.