My applications on STB requires quite a lot of time when switching the screens.. initially I suspect it might because of parsing xml ... so I change from nano to the one apenz adopts. (thanks apenz:)) ,but the speed does not change much.... then I change all Vector to ArrayList... but still, the first time switching a screen is slow.. subsequent switching is very fast... any one has suggestions regarding how to make it faster? thanks
One good thing to do in a case like this is to measure where the time is being spent. Unless you have a really good relationship with an STB manufacturer, you probably can't use the built-in profiling in a debug build of the STB middleware, though, so you have to profiling with application-level timers.
Over at the hdcookbook project (hdcookbook.com, click on "HD cookbook open-source project), we have a putback pending that adds some tools you can use for this kind of profiling. Since the timer granularity on a BD-J or MHP terminal isn't very fine, it works by sending UDP packets to a PC with a higher-resolution system clock. In some tests yesterday I got quite good results using this technique; hopefully by the end of today we'll have a putback that includes a writeup -- look in <cookbook>/AuthoringTools/profiler/README.txt on Monday if you want to go down this path.
One area that often is slow is parsing XML, or any other text-based format. Parsing a text file format on a client device is just inherently slow. A technique that's usually much faster on the client device is to pre-parse any XML or other text data into a simple binary format you control - you pay the parsing hit at compile time, or at worst on a fast server computer. There are "Binary XML formats" (see http://en.wikipedia.org/wiki/Binary_XML), but often a format of your own devising is a good thing to do, particularly if you have a file type that will be relatively stable, and used widely.
For example, in the GRIN scene graph (also in the cookbook repository), we always ship the declarative scene graph files as a compiled binary. GRIN is a pretty sophisticated example, but if you want to dig around, look for things like GrinBinaryWriter.java and GrinBinaryReader.java in the repository.
thanks for the reply.
May I know for parsing xml and text file, besides the pre-parsing , any other means which could make the process faster? now I am using SAX parsing of xml, compared to parse txt file, any big performance differences? Besides parsing xml, any other factors in programming could also cause the slow loading of screens? thanks
You can try putting all your data in an ini-file.
That how I do it. I usually parse any page I need in under half a second by loading the ini file directly into a Properties Object via ByteStream.
No unnecessary transformations or anything and direct access to all info.