Add hex values for byte arrays instead of reading them from tables (for faster start up)

[donv]

This shaves 200 ms off typical Ruboto startup. Discussed with Enebo, but needs broader consent.

[enebo]

@lopex This change seems safe enough since non of the values are close to hitting 32k initialization limit and it seems to make a measurable amount of time off Dalvik. Any concerns with landing this?

[enebo]

Talked with @lopex on irc today. He plans on looking at the statics your patch affects and he will see if all of those are required as part of startup. If they are not then he will make them load lazily. For the others we can go the route you want but you need to generate this source as part of one of the scripts in scripts/*.rb to generate this. The file in question has at least some portion made by these scripts. I would recommend asking @lopex questions on how best to modify that script and I hope he will update this issue on what he figures out on whether some of these fields can be loaded lazily (because they are not needed for startup).

[lopex]

@rscottm .For now we've made table loading lazy, only patterns with explicit ignore case and unicode like /foo/iu triggers tables to load (and even this triggers only two tables). If this change is not sufficient we'll go inline tables and java source generation. Is that ok ?

[rscottm]

Sounds like a good improvement (I think I was seeing 11 tables loading).
We'll see how it goes.

On Wed, Aug 14, 2013 at 3:55 AM, Marcin Mielżyński <notifications@github.com

wrote:

@rscottm https://github.com/rscottm .For now we've made table loading
lazy, only patterns with explicit ignore case and unicode like /foo/iu
triggers tables to load (and even this triggers only two tables). If this
change is not sufficient we'll go inline tables and java source generation.
Is that ok ?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/6#issuecomment-22627818
.

[headius]

I'm going to guess the lazy-loading was sufficient and close this.