On Thu, Sep 4, 2008 at 7:53 PM, Bruce Johnson <[EMAIL PROTECTED]> wrote:
> 1) Is there anything about the structure of these tables that could
> unusually affect performance, especially startup time (e.g. forcing unusual
> parsing code paths in the JS engine, putting unreasonable pressure on the
> GC)? I wouldn't expect that to be the case, but it's important to ensure
> that we're unlikely to be triggering any pathological JS VM behaviors if the
> code/data structure is particularly unusual.
>
Here is a sample generated class:
public class DigitTable {
// Compression block size is 8192
// Total delta range = 0 to 1
// 23 total codes, theoretical minimum payload bits needed=172
private static class Instance {
private static CodePointTable instance = new CodePointTable(symbolTable,
compressedTable);
}
private static String symbolTable = "Z:iRZAZ^;[EMAIL PROTECTED]
[];`DEaBFsl:[EMAIL PROTECTED]@@aC?kl:[EMAIL
PROTECTED]@F;wJFJT[]LHFR=TgRk?wsl:[EMAIL PROTECTED]";
private static String[] compressedTable = new String[] {
/* Block 0 */ "QDEq<B]FTl>SBnTEOpUGr:",
/* Block 1 */ null,
/* Block 2 */ null,
/* Block 3 */ null,
/* Block 4 */ null,
/* Block 5 */ null,
/* Block 6 */ null,
/* Block 7 */ "ViZ",
/* Block 8 */ "Wj:",
/* Block 9 */ null,
/* Block 10 */ null,
/* Block 11 */ null,
/* Block 12 */ null,
/* Block 13 */ null,
/* Block 14 */ "XzYZ",
};
/**
* Returns isDigit for a given codePoint.
*/
public static boolean isDigit(int codePoint) {
return Instance.instance.lookupBinaryProperty(codePoint);
}
/**
* Prevent instantiation.
*/
private DigitTable() {
}
}
So, the only thing would be having to process potentially long strings.
There are at most 137 strings and one array defined per table, usually less
as above. I thought about changing from null to '' for the all-zero blocks
to save two bytes per entry, but on IE that will generate additional
objects. When a block is decompressed, it is stored in an array of 256
primitive numbers for binary properties or 8192 primitive numbers for value
properties. There can be at most 136 of them, and they are only
decompressed on demand so usually it will be far fewer (for example,
virtually all currently active non-Asian languages with a significant
literate population would fit in the first block).
BTW, note that the above data represents the isDigit information for all
one-million+ Unicode characters, so the compression ratio is pretty good :).
2) Have you discussed with Lex and Scott how amenable your scheme is to
> GWT.runAsync()? If you can ensure that it's designed such that you could
> download the decompression/parsing code and data tables after the startup
> fragment, that would be ideal. I *think* runAsync() can move global
> constants into separate fragments, but it's worth double-checking before you
> commit to an implementation.
>
As Scott mentions, we can't do that directly but if the developer isolates
the code that uses them into isolated sections the decompression code and
data can be isolated as well.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
