I ran a few test to check memory issues. If I populate a TextElement with 100,000 characters and then do just one createTextLine I see the memory usage jump about 18 megabytes. So I create one textline, do not add it to the display list, and I see the memory increase. If I don't call createTextLine (but do everything else), then I do not see the radical increase in memory usage. I paired this down to 50,000 characters and to me it looks like somewhere on the order of 150-200 bytes is being used for the storage of each character. Just a guess but can someone shed some light on this.
Seems to be a direct correspondence between number of characters and the extreme use of memory for each character, so that is how I arrive at the approximate 150-200 bytes per character.
Since this has nothing to do with reusing textLines etc... Is this kind of issue resolved in 10.1 ?
Don
An engineer who worked on these 10.1 improvements gave me sone additional information that is worth sharing:
2-10 bytes per character is the permanent data structure that's needed to render lines. We still consume 30-120 bytes of temporary data during the creation of this structure (30 in the common case, 120 in other cases with non-default styling or circumstances). Numbers are approximative.
Gordon Smith
Adobe Flex SDK Team
Thanks for checking this out Gordon.
If I am following you correctly, then each time say the width of the container has changed, and we need to recalc all the lines, then this 30-120 bytes of temporary storage will be needed for each character ?
If that is correct, then in the 100,000 character case, each time container is resized then anywhere from 3 to 12 megabytes will be needed for temporary storage ?? yeah confused
Seems more likely you mean 30-120 bytes extra needed for whole thing, but that would not be worth mentioning... lol
Could you please clarify ?
Thanks,
Don
Since TextLines are created one-by-one, I believe Player 10.1 needs to use 30-120 bytes of temporary memory per character in that line. So if there are 100 characters in the line, that would be 3-12K of temporary memory. Once the TextLine is created, that memory can be released. Then the next TextLine needs 3-12K of temporary memory. I'll check this with the Player engineer and get back if this is incorrect.
Gordon Smith
Adobe Flex SDK Team
There are two data structures that contribute to the memory picture.
One is a "temporary" data structure that is used for the creation of the TextLines of a TextBlock. This data structure has ~one entry for each character in the TextBlock. In 10.0, the per entry cost is more or less what you have measured (150 bytes). In 10.1, we have arranged to make that structure ~30 bytes for many common cases, but it remains ~100+ bytes in others.
The other is the data structure that describes the content of a TextLine. In 10.1, that data structure contains all the data necessary to display the line, determine atom boundaries, etc It is ~ 2-10 bytes/character, with 2 being a common case for English text, no kerning.
In 10.1, we also added a method on TextBlock that lets you release the "temporary" data structure. It will be recreated when needed (e.g. you change the content of the TextBlock and/or you create new lines from it).
Ok, so quite abit of memory is allocated per character, when unicode character takes 2 bytes. 15 times the memory to store character on a probably on going need to keep that temporary memory in place especially in the dynamic resize case.
Seems to me that this is a perfect structure for Run Length Ecoding. It can be faster, it is simple, and can save a ton of memory.
So save the required structure, and then a run of characters that the structure addresses. If lookup is an issue then that is easily addressed.
Of course I am not privy to your actual needs and requirements.
Don
North America
Europe, Middle East and Africa
Asia Pacific