ICU-20392 Split the Locale payload into nested and heap allocated #3518
Conversation
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
All the most commonly used Locale objects have very little payload, most of them don't use any extensions, don't use a language tag longer than 3 characters and don't use more than a single variant. There's room for all that data in a simple 32 byte large payload object, which can be nested directly in the Locale object. Any payload larger than that can instead be heap allocated as needed, in order to save storage for the most commonly used objects while retaining the ability to create arbitrarily large and complex Locale objects. This reduces the storage requirements for all Locale objects. For nested payloads, this reduction is from 224 bytes to 48 bytes. For payloads that need to be heap allocated, the reduction depends on several factors, but for most cases there's some reduction. There are also cases where this refactoring actually increases the storage used, because CharString allocates more storage than necessary. There are a number of ways in which this could be improved upon, such as optimizing CharString to not allocate more than necessary when copying a string of known length, not allocating any empty CharString objects or possibly replacing CharString with a new class for fixed length strings. The public API remains unchanged but the operations which can lead to U_MEMORY_ALLOCATION_ERROR change.
|
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
All the most commonly used
Localeobjects have very little payload, most of them don't use any extensions, don't use a language tag longer than 3 characters and don't use more than a single variant.There's room for all that data in a simple 32 byte large payload object, which can be nested directly in the
Localeobject.Any payload larger than that can instead be heap allocated as needed, in order to save storage for the most commonly used objects while retaining the ability to create arbitrarily large and complex
Localeobjects.This reduces the storage requirements for all
Localeobjects.For nested payloads, this reduction is from 224 bytes to 48 bytes.
For payloads that need to be heap allocated, the reduction depends on several factors, but for most cases there's some reduction. There are also cases where this refactoring actually increases the storage used, because
CharStringallocates more storage than necessary. There are a number of ways in which this could be improved upon, such as optimizingCharStringto not allocate more than necessary when copying a string of known length, not allocating any emptyCharStringobjects or possibly replacingCharStringwith a new class for fixed length strings.The public API remains unchanged but the operations which can lead to
U_MEMORY_ALLOCATION_ERRORchange.Checklist
ALLOW_MANY_COMMITS=true