PDF Presentation - Uplinq

Brew MP
Performance Tips
Rich Stewart, Sr. Director, Technology
QUALCOMM

Objective
• Provide a general overview of performance
considerations
• Share BMP specific performance tips
2

Agenda
• Performance Concepts
• BMP Architectural Overview
• CPU Utilization Considerations
• Memory Utilization Considerations
• Power Utilization Considerations
• Tools
3

4
Performance Concepts

General Performance
• What is optimal performance
– Execution time
– Response time
– Memory utilization
– Power consumption
• Optimal performance involves achieving a balance of all
performance factors
• Optimal performance involves sharing system resources
• Optimal performance enables an optimal User Experience
• The performance of a ‘crashed’ system is ZERO
– user experience == 0
5

Trading Off Throughput vs. Latency
Signal + Worker Thread Example
• Your application must balance work throughput with latency
– Real-time apps (example: audio/video streams) must process small
amounts of data regularly; low latency at the cost of context-switch
overhead
– Best-effort apps (example: downloads, file compression) are only
concerned with reaching the “finish line” as soon as possible; low
processing overhead at the cost of increased latency
6

Throughput vs. Latency (cont.)
• Example: A TCP throughput test application with configurable delay
• Peak throughput occurs on this system at 10–12ms
– Read too frequently and burning excess CPU
– Read too infrequently then we leave throughput on the table
• TCP Window is filled after 20ms; throughput drops drastically
7

Throughput vs. Latency (cont.)
• Delay as much rendering/processing/parsing as long
as reasonable
– Application context t has higher h priority it than Packet
Services context
– Crunching incoming data before the whole transfer is
done has user-experience penalties
– Try to manage in-transfer screen updates (e.g., show
progress bar instead of progressive rendering)
8

Trading Off CPU vs. Memory Utilization
• Your application must balance CPU and memory usage
(space-time tradeoff)
• Example: data compression
• Advantage―lower filesystem usage
• Disadvantage―higher g resource load times
• The nature of your application determines the critical
resource
• “Is 5x data compression worth a 2x time penalty”
• “Is a 2x time speedup worth a 4x larger data file”
9

Data Cache Performance Implications
• Write cache-friendly code by using temporal and spatial
locality; keep as much data in your caches as possible
• Improves execution time and saves power!
• Example: Process a two-dimensional array
row-by-row (good spatial locality)
for (i = 0; i < numRows; i++)
column-by-column (bad spatial locality)
for (j = 0; j < numColumns; j++)
for (j = 0; j < numColumns; j++)
for (i = 0; i < numRows; i++)
process(array[i][j]);
process(array[i][j]);
10

Event Handling
• A backlog in the event queue translates into perceived delay for the user
– Validate that the event arrival rate of your design, combined with the other system events can be
processed by the system without a queue becoming so deep that it impacts the users perception
of responsiveness, or that the system elects to drop events
– When exceeding this threshold one needs to consider if the "event" being processed is more
optimally treated as data. Touch screen events are a common example. Handwriting recognition
improves with the number of samples per second. Treating every sample as an event can flood
the even handling mechanism. Grouping down events into a list of data, with a time derived event,
can improve performance.
• Event prioritization and/or creating independent UI tasks can have an advantage
– Take the example of a single threaded UI downloading a web page. If single threaded, and polling
a queue, the page download would not be interruptible until the download is complete. This is an
extreme hypothetical, example.
• Do not use the event queue as a polling mechanism
– For example, in Brew ® , do not post an event to yourself, check some conditions in the event
handler, and then re-post the same event if the condition hasn't been satisfied yet. If you must
periodically check some condition, use a timer with a non-zero delay and check the conditions
in the timer callback handler.
11

Strings
• Use AEEstd.h in lieu of AEEStdLib.h
• Unnecessary function calls (empty string check):
– Bad:
• if (0 == std_strlen(psz)) {...}
– Good:
• ('\0' == *psz) {...}
• Buffer string lengths when you need them multiple times
– Bad:
• std_ strlcpy(dest, string1, MAX_ STRING_ LEN);
• std_strlcat(dest, string2, MAX_STRING_LEN - std_strlen(string1));
• std_strlcat(dest, string3, MAX_STRING_LEN - (std_strlen(string1) + std_strlen(string2)));
– Good:
• int length = std_strlcpy(dest, string1, MAX_STRING_LEN);
• length = std_strlcat(dest, t t(d t string2, MAX_STRING_LEN - length);
• std_strlcat(dest, string3, MAX_STRING_LEN - length);
• Concatenation, use strcat(), not strcpy():
– Bad:
• std_strlcpy(dest + sstd_trlen(dest), source, MAX_STRING_LEN - std_strlen(dest));
– Good:
• std_strlcat(dest, source, MAX_STRING_LEN);
12

Strings (cont.)
• Don't call strlen() on #defined strings or strings that are
in-lined
– Use (int)(sizeof(string)-1) or an appropriately defined macro
• See if a built in string function exists to meet your
use case
– There are many built in string functions, some obscure
• Iterate once through the string for complex operations
– Each pass through a string can be viewed as a linear search in cost
– For highly complex string operations consider implementing a
state machine
13

Diagnostic
code
• Code which does not directly contribute to the user’s s experience within
an application reduces the overall user experience of the ‘system’
14

15
BMP Architectural Overview

Device Platform Overview
Brew MP provides an extensive set of APIs into features at all
layers of the device, including:
• OS Services
• General, Multimedia and Modem Services
• Application, Widget, Windowing and UI Services
Brew MP is both modular and extensible. Many of the services
are offered as demand-loaded, digitally signed binary modules.
This serves to reduce static RAM overhead, bolster compatibility
between devices and support flexible configurations.
The platform supports both cooperative and pre-emptive
threading. It also supports process-based memory protection
which complements the already robust least-privileged execution
model of the platform.
Brew MP has been optimized to leverage chipset modem
and multimedia services. These services are exposed through h
immutable object-oriented APIs which support seamless access
to hardware accelerated implementations when available.
A key principal of Brew MP is platform extensibility. New features
and APIs can be added without Qualcomm’s involvement. These
features can be exposed through any supported language.
Applications
Application Environment
General
Services
OS Services
Kernel
3 rd Party Software
Brew MP Software
Chipset Software
3 rd Party Apps
Graphics &
Multimedia
(HW
Accelerated)
Modem &
Networking
16

Leverage the Functionality Provided by
the BMP System
• Components in the Brew MP
System are optimized for
– Power
– Execution performance
– Memory utilization
stem✔Do IT!
• Optimization of Brew MP System
Components is chipset specific
– Using these components will utilize
the underlying hardware where
possible
✔Please utilize Brew MP APIs
where applicable
17

Brew MP API Usage Considerations
• New Brew MP APIs are generally improved over
Brew 3.1.5 legacy interfaces
– BrewMP ISockPort replaces Brew3.1.5’s 315’ ISocket interface
• Reference:
https://brewmobileplatform.qualcomm.com/devnet/docviewer.jspm
ethod=show&id=5790&path=%2FdevEx%2Flibrary%2Ftechguides
%2Fc%2Fnetworking%2Fnetworking_tech_guide%2Fhtml_out_oe
m%2Fframeset.html
– IFileSystem2
– Minimize calls to GETTIMESECONDS and GETUPTIME
• Frequently called by app more often the necessary
• These calls have have a relatively high performance cost
– GETTIMESECONDS has the higher overhead of the two
18

Brew MP API Usage Considerations: Scheduling
Work
• Always use ISHELL_Resume to break an IApplet’s
time-consuming tasks into smaller, interruptible chunks
use
– A common performance mistake is to use
ISHELL_PostEvent() for this purpose, p which works
functionally
– ISHELL_PostEvent() is more costly than
ISHELL_Resume
• ISHELL_PostEvent() destination applet class ID as argument
• Iterates through the applet database to match the class ID
19

20
CPU Utilization Considerations

JPEG Decoding Optimization
• 5Mp image decoding time vastly improved with 1/8 scaling factor
• IDownSample API: Integer DownScaling While decoding (1/8, 1/4, /1/2)
• AEECLSID_GenericViewerAsync: Prevent hogging UI while decoding
• Also a great memory saving as the generated bitmaps are close to QVGA
IDownSample Fidelity Window
Scaled Decoded Image
Factor 1/8 or 1/4 or 1/2 or 1:1
Factor selected against the
fidelity size.
The highest scaling factor
meeting the fidelity minimum size
requirement
ERR_BAIL(IEnv_CreateInstance(pMe CreateInstance(pMe->piEnv, AEECLSID_JPEGDecoder, (void **)&piImageDecoder));
nErr= IIMAGEDECODER_QueryInterface(piImageDecoder,AEEIID_IDownSample,(void**)&piDownSample)
if(AEE_SUCCESS == nErr)
{
if (NULL != piDownSample){
IDownSample_SetTargetFidelity(piDownSample, fidelityX, fidelityY);
}
}
ERR_BAIL(IEnv_CreateInstance(pMe->piEnv, AEECLSID_GenericViewerAsync, (void **)&piImage));
IImage_SetParm(piImage, IPARM_DECODER, (int)piImageDecoder, 0);
21

Resource Usage: Reduce Number of Images
• Reduce number of
images and widgets to
be used (e.g. If you
have a key that shows
lower and upper case,
use one static widget
per key instead of two
to save time to display)
This key can be done
with one static widget
instead of two
22

Resource Usage: Use Bitmap Fonts or Simple
Typeface Fonts
• Font execution
and memory costs
– $ BitMap
– $$ Simple True Type
– $$$ Complex True Type
• Font render quality
– ✚ BitMap
– ✚✚ Simple True Type
– ✚✚✚Complex True
Type
23

Resource Usage: Merge Static Images
With Background Images if Possible
• If there are some static images that are always displayed, merge them
into the background
Screen to show
different shapes on
the top portion only
But the lower
portion remains the
same, but these are
always loaded!
Background has a
plain color
Should use this as
the background
24

Resource Usage: Avoid Blending in Run-time
• If two images can be composited at authoring time rather than runtime,
they probably should be, as this can be a way to reduce use of alpha
blending
If these images are always blended in run time,
and can be composited at authoring time
Then, load this image instead
of loading 2 images and then
blending
25

Resource Usage: Use Fixed Height for Lists
• Use fixed height for
different rows to be
displayed on Forms,
if multiple lines are
needed, try to fit into
a fixed height
Fixed height
to avoid
computation
during
run-time.
26

Resource Usage: Preloading and Reusing
• Pre-loading an application or images if it’s time critical to
start that application or image. This has a negative impact
on boot time
• Pre-loading can be deferred and doesn't need to occur on
app startup. Once the app has started, a background task
can be used to progressively pre-load resources that t will be
needed later on. Or if the image is hidden, don’t load it
during app startup
• Cache the local time offset. Update only on a widely spaced
interval (minutes) or at the beginning of a short duration
use case
27

Resource Usage: JPEG/PNG vs BMP
• PNG and JPG require performance costly decoding
• Non-transparent (opaque) images may be converted to bitmaps
– Increase the size of the bar file, but will lower load time
• BMP (left), vs. PNG (right) format quality comparison
bmp file: 232KBytes
png file: 46KBytes
• Use PNG if you would like to use the transparency feature
A is transparent to B
A is opaque to B
28

Resource Usage: Use PNG Crush
• Encoding PNGs without “rowfilters” faster decodes
– Cost is a large PNG file
– Negative implications for EFS and RAM usage
– Leads to an overall decrease in system performance
• Recommended pngcrush options
– pngcrush -f 0 to minimize RAM and EFS usage
– pngcrush -rem tEXt to remove unneeded text added by
authoring tools
– pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB
• To remove chunks for gamma and color correction tables
• Use the pngcrush –brute for broad spectrum optimizations
29

Resource Usage: Additional PNG
Performance Hints
• Don’t use interlaced PNGs
• ARGB with unused “A” – alpha channel convert
to RGB
• Some images that are 24 or 32 bit can be more
efficiently (and without loss of fidelity) encoded
as a palletized PNG
• Filmstrip type animations can be really large
– Using an animated GIF should be used if an undue
loss of fidelity is not realized
30

31
Memory Utilization
Considerations

Resource Usage: Use Widget Properties
• Use Iwidget to set properties to display
vs loading an image file
– Smaller and faster
– Loading
if_textinput_qwerty_alphabet_bg.png
(320x240 pixels)
– Should use the following for better
performance
• tif_qwerty_alphabet_title.png (320x21 px)
• IWidget_SetGradientStyle(GRADIENT_STYL
E_CENTERVERT)
• IWidget_SetGradientColor(219,
222,227)
• IWidget_SetBGColor(222,227,231)
Background with
a plain color
Background with a plain
color and gradient
32

Storage Optimization: Use a Smaller Image for Tiles
Instead of a Full Image
• Use a smaller image that will be tiled, instead of a large image
Large image: 159K Bytes
Small image: 19K Bytes, can be tiled
33

Database Applications Optimizations
• Database Update — dbc_IStatement
– Disable Journaling when data integrity is not required (SQLite Pragma)
– Minimize db operations (query/update):
• Use transactions
static const char* cpszPragma = "PRAGMA journal_mode = PERSIST;"
// static const char* cpszPragma = "PRAGMA journal_mode = OFF;"
nErr = DBCConnection_New(pszPath, me->piEnv, po, eFlags, ppic);
cpszUpdate = cpszPragma;
ERR_BAIL(dbc_IConnection_CreateStatement(*ppic, cpszUpdate, &nTail, &pis));
ERR_BAIL(dbc_IStatement_ExecuteUpdate(pis))
– Use Cache (control cache size via SQLite Pragmas)
• Database Queries
– Refer to Database Technology Guide —
https://brewmobileplatform.qualcomm.com/devnet/index.jsp#databases
34

Memory Management Considerations
• Avoid fragmenting heap
– See next page for explanation of heap fragmentation
• Consider using block allocator
– for (i=0; i

Brew MP-Specific Techniques to Avoid Heap
Fragmentation
• Example of heap fragmentation
16KB used
48KB free
1:
first alloc
16KB used 16KB used 32KB free
first alloc second alloc
2:
16KB used 16KB used 16KB used 16KB free
3:
first alloc second alloc third alloc
16KB used 16KB free 16KB used 16KB free
4:
first alloc
third alloc
36

Apply Brew MP Best Practices to Avoid Memory
Corruptions
• The performance of a ‘crashed’ system is ZERO
• Release all BMP API’s through IQI_RELEASEIF().IQI_RELEASEIF
– Ensures only memory of a non-null null API pointer is released
– After the release the pointer will be set to NULL
• All the FREE() should be replaced with FREEIF()
– FREEIF() will ensure that only memory of a non-null null pointer is freed
– After the free, the pointer will be set to NULL
• Only use the version of the helper functions that accept “size” as one its
parameters for boundary checking. This includes functions like strncpy,
snprintf, etc… This will avoid any possible buffer-overrun.
37

Some Simple Tips for Memory Leaks
• Analyze any possible memory leak reported by BMP
– Typical message from the logger
• *AEEModule.c 00266 Warning—memory leak, freeing, 0xABCD1010, NONAME,
size 328
– Indicates a memory leak of 328 bytes from memory address 0xABCD1010
– The source of the memory is NONAME because the memory block was
not tagged
– To enable the heap blocks to be tagged with the filename/linenumber, insert
• “#define AEE_DEBUG_HEAP 1” before the app includes AEEStdLib.h.
• Remove this #define before shipping i commercial product
• *AEEModule.c Leverage c_heaptracker app to track app’s heap usage
over time to see whether the available heap keeps decreasing for no
reason
38

39
Power Utilization
Considerations

Power Management
• Avoid/minimize periodic wakeups
• LEDs and LCD burn an enormous amount of power
– Turn off the keyboard backlight when not needed
– Turn off the display when not needed
– Turn off the backlight when not needed
• Apps responding “TRUE” to EVT_APP_NO_SLEEP
defer entry to BLPM by 10 seconds
• Responding “TRUE” burns power
40

Power Management—Minimize Number of Wake-ups
• Avoid using periodic timers to wake up the phone
• An example of waking up every 5 seconds may reduce the standby
time by 29%!
Idle power
consumption
is really low
Each wake up
consumes lots
of power
41

42
Tools

Principles of Code Optimizations Using
Profiling Tools
• Timing data in the profiler report in Simulator is not the
same as that of the phone. Sometimes they are not even
proportional.
• Profiling report by PC tools (e.g. GlowCode) is still helpful
in shedding light into the behavior of you module on target.
– The time spent in a function and its children. This lets you
follow the “hot path”—the series of function calls responsible
for the majority of the execution time.
– The number of hits in a given function. Function with higher hits
could be part of the “inner loop”, and should be looked at with
more carefully.
43

Sample Output for basicmod1app Module
Inner-loop: HandleEvent
Hot-path: dbg_Message: 13.8%
44

CS Heap Tracker (CHT)
• CHT is a utility to debug memory leaks, double-frees, writing past allocated memory, etc.
• Support for simulator and on-target debugging
• CHT provides, in the instance of detected heap corruption, a stack trace of the offending function
• Also supports high watermark tracking
45

46
Conclusion

Summary
• Performance is comprised of many components
– Execution time
– Response time
– Memory utilization
– Power consumption
• Optimal performance is achieved through making tradeoffs
• These tradeoffs are most effectively made through
understanding the application specific considerations and
general system considerations
• Ultimately the application user experience and overall user
experience of the system defines optimal performance
47

48
Additional Information

Resource Usage: Miscellaneous
• Images that are reused several times should be cached
and not re-loaded from the file system
– Make the application as a singleton if it is expected to be
used for multiple applications. E.g. virtual keypad that is
used by messaging, email, dialer applications.
• If the device is performing slowly when flickering,
you may have to increase the Event Expiration Timer
(IObserver_SetPointerEvtExpirationTimer) toimprove
the performance of list flicks (perhaps a value closer to
1 second instead of the default 150ms) to get a longer
sampling rate of the pointer events
49

50
CHT Example: Double-free