Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

Issue 16    December 20, 2000 *Editor's Note: Due to holiday scheduling there will be no BMessage the first Wednesday of January. Look for the next issue on January 17. Be in the News December 12, 2000 Be's Aura: The MP3 Home Stereo, Byte.com return to top Jean-Louis Gassée Column by Jean-Louis Gassée There is no column from Jean-Louis this week. You may peruse his past articles here. return to top Device Management: The Next Frontier of User Friendliness By Severine Corruble, Director of Operations An aspect of internet technology that's often overlooked is its capacity to be used as the conduit for managing on-line computers and internet devices. In other words, the internet can deliver more than just images, sounds, software, and credit card forms to the user's computer; it can also be used by a central server to pro-actively monitor client devices, and to deliver and install software that improves the devices' performance and fine tunes the interface. Furthermore, this can be done transparently, without the user's intervention -- sometimes without the user even knowing that the device has been modified. For the user, remote device management means no more trips to the computer store for software upgrades. But there are more subtle benefits as well. For example, the server can "guide" the user's experience by monitoring the user's favorite sites or Web topics, and downloading new interface files (banner ads, reminders, bookmarks) that are tuned to the user's taste. Or the server could notice that the user has shown an interest in buying a product on-line and quickly do some comparison shopping on the user's behalf ("Perhaps you'd like to save $20 by buying the identical shoes from ShoeStore.com?"). The device vendor also benefits from remote device management: The cost of direct support by telephone or email, particularly as it applies to software installation, is nearly obviated; the ability to direct users to "favored" sites, and to place advertisements on client machines can provide new sources of revenue; the ability to automatically update device software to support new data formats and application features means the user can be kept in the fold. To fit the needs of a complete remote device management system, Be has devised MAP, the Management and Administration Platform. MAP provides all the software a vendor needs to create and manage a database of client devices. MAP's features fall into four categories: Registration and Authentication. MAP can automatically register a new device when the user turns it on for the first time. The extent of the registration--how much information you want to gather about the user--is up to the vendor. It can be as simple and transparent as sending the ID number of the machine to the MAP server, or the user can be asked some "taste and lifestyle" preference questions. Thereafter, MAP can authenticate the device whenever it tries to access the ISP. Remote Management. As soon as a piece of software leaves the factory, it's obsolete. New formats and features are invented that the old software doesn't support, but that users demand. Through remote management, new software--from incremental updates, to individual applications and plug-ins, to entire system upgrades--can be downloaded and automatically installed. User Experience Management. MAP makes fine-tuning the user experience much more flexible. Pre-defined user interface packages based on the user's taste and lifestyle can be downloaded, either automatically or at the user's request. Since these UI packages are downloaded from a server rather than shipped with the device, size isn't an issue--the array of choices presented to the user can be limitless. And, of course, UI choices work both ways: The more the user defines the UI he or she wants, the more information the vendor can gather about the user. If the user asks for the "Family Filtering" package for example, the vendor will know that certain banner ads may not be welcome on that device. User Applications. MAP also provides server-based tools and applications that are purely for the user's benefit: A calendar, address book, instant messaging, document viewer, email client, and so on. An intelligent and compelling combination of these features will truly make internet access easy and ubiquitous. return to top It's About Time By John Dance, Engineering Director, Development Tools Have you felt dissatisfied by the performance of an application you were writing? If you haven't, then I'd like to see that application, and please send us your resume. In any case, take a look at http://www.be.com/jobs. Even if you're not perfectly satisfied with the application you've written, you might not have realized that we have some tools on BeOS to help find performance problems in your application: profile and bprof. Their functionality, however, has been limited in various ways, primarily because they failed to work correctly with add-ons. While you can work around this problem in most cases by just linking with the add-ons, it would be better if the tools worked with add-ons out of the box. Another difficulty has been that bprof was limited in what it could report. Fortunately, we have some good news for you about these problems that I'll discuss later in this article. profile & bprof Let's backup for a minute and talk about how you run these tools and how they work. The profile tool is the easier one to explain. Just run "profile myApp" from the command line. When you quit the application, a pc sampling report, which shows the "hot spots" in your app, is written to the Terminal for each thread in your application. At intervals, profile peeks at the application and records where it found the program counter. These counts are then tallied per function for a final count per thread. % profile ProfileTest Loading symbols from: /boot/home/Tests/ProfileTest Loading symbols from: /boot/home/Tests/lib/MySharedLib.so Loading symbols from: /boot/beos/system/lib/libbe.so Loading symbols from: /boot/beos/system/lib/libnet.so Loading symbols from: /boot/beos/system/lib/libroot.so Loading symbols from: /boot/beos/system/lib/libtextencoding.so Thread 47974 - ProfileTest Total # of program counter samples for thread 1340 #Hits %Pct Name 739 55.15 0xec91d25c - CopyStrings(char const *) 565 42.16 0xec068dc0 - strlen 14 1.04 0xec91d1bc - ReverseString(char *) 5 0.37 0xec066ab0 - strcpy 3 0.22 0xec0849bc - _get_system_info 2 0.15 0xec0846dc - _kwrite_ 1 0.07 0xec08f134 - _free 1 0.07 0xec08f038 - _malloc 1 0.07 0xec08e0c4 - _malloc_internal What does this result tell us about our ProfileTest application? First, we need to look at CopyStrings and see how we can optimize that function. CopyStrings alone takes over 55% of the execution time. When you get a profile result, though, take the time to look for less obvious trends too. Notice that while the hit counts are small, there are some in _malloc, _malloc_internal, and _free. In combination, these tell us that our program is doing a lot of memory allocating and freeing. Is it doing more than necessary? We should make a note of that as we look for optimizations. (In this specific example, the hit counts are really too small to infer this, but the idea is correct. Look around at some of the less obvious hot spots or at a combination of them that shows a trend.) Now, what about strlen? I'm glad you asked. There isn't much optimization we can perform on strlen, but who is calling strlen, and does it need to be called that often? Here is where bprof can help us. Profiling with bprof is a multistep process that requires recompiling your code. Code is compiled into your application to keep track of each function call and the time spent in that function. The profiling accounting code is called by a hook that is inserted by the compiler at the beginning and (effectively) end of each function. bprof then interprets this information. To use bprof: 1. Compile and link with the -p flag. You can add -p to your compilation and link flags in your makefile, or you can use the BeIDE to do it for you automatically. (see Project Settings/x86 Code Generation). 2. Run your application normally. 3. Run bprof on the profile_log. file written when your application quits. Let's see what bprof reports for our ProfileTest: % ProfileTest % ls profile_log.* profile_log.23925 % bprof profile_log.23925 /boot/beos/system/lib/libtextencoding.so: /boot/beos/system/lib/libroot.so: /boot/beos/system/lib/libnet.so: /boot/beos/system/lib/libbe.so: /boot/home/Tests/lib/MySharedLib.so: 400 227798 us 407393 us - CopyStrings(char const *) 400 177377 us 177377 us - ReverseString(char *) 400 774 us 774 us - my_strcpy(char *, char const *) 1 314 us 409394 us - TestProfiler 200 186 us 114525 us - CopyShortString(void) 200 181 us 293863 us - CopyLongString(void) /boot/home/Tests/ProfileTest: 1 159 us 409558 us - main These results are also interesting. The columns give us the number of times that function was called, the time spent in that function, and the time elapsed in that function. (In other words, time spent in that function and its children.) First, we can verify the function counts and make sure that we aren't calling something too many times. Next, we can look at the function times and see how they compare to the results from profile. We knew that CopyStrings was a problem, but notice that since libroot isn't profiled here, ReverseString has the second highest time. How much do you want to bet that ReverseString is related to strlen from our previous results? (Don't take the bet.) Finally, the elapsed time gives us a clue to who calls a function that takes a lot of time. Perhaps we can't optimize the function itself, but we can optimize the number of times it is called. As it turns out, CopyString has some obvious optimizations that we can perform. char* CopyStrings(const char* longString) { // waste time for (int i = 0; i < kDummyCount; i++) { dummy = (dummy / .325) + i; } char* newString = new char[strlen(longString) + 1]; my_strcpy(newString, longString); ReverseString(newString); return newString; } ReverseString could use some changes too: void ReverseString(char* string) { for (uint i = 0; i < strlen(string)/2; i++) { char temp = string[i]; string[i] = string[strlen(string)-i-1]; string[strlen(string)-i-1] = temp; } } The changes that need to be made are obvious. However, even in real applications, after looking at the results of bprof and profile, some changes are often obvious. There is often low-hanging fruit that can easily be picked after you profile your code. Optimization Rules of Thumb As a preface, don't optimize too soon, and don't optimize without profiling.Otherwise, you might take enormous pains to optimize some function that takes less than 1% of the time to begin with. If you improve that function by 50%, you have improved your application runtime by only .5%. 1. Use a combination of profile and bprof to find hot spots and who is calling those hot spots. 2. Look for low-hanging fruit -- small changes with big impacts. 3. While concentrating on the biggest problems, look for less obvious trends in the profiling results. Hypothesize and then go to the code to validate that theory. 4. Check the function counts reported with bprof to see if they make sense. Often function counts alone can point out problems or bugs. 5. Use the elapsed time in bprof to target who is calling time consuming functions. 6. After making a change, rerun the tests to verify improved results. Also, look for any new hot spots that rise to the top. Don't Try This at Home If you try using these tools included with BeOS 5.0, you'll find that they don't work with add-ons. The profile tool attributes all the time spent in the add-on to "_end". The bprof tool just ignores the add-on. In addition, the BeOS 5.0 bprof doesn't show elapsed time. New Tools You can find new versions of profile, bprof, (and a new libroot.so that is needed for add-on and elapsed time support in bprof) at ftp://ftp.be.com/pub/experimental/tools/ProfileTools_x86.zip. You'll also find a header file that describes how you can now turn bprof style profiling on and off to examine only certain sections of your application. If you're uncomfortable using tools and libraries that haven't been through a normal testing cycle (and you should be), please save your original versions. You might even think about putting libroot.so in %A/lib only when profiling. The new tools should help you pinpoint and fix performance problems. After all, it's about time. Isn't it? return to top Statements contained in this Newsletter that are not historical facts are "forward-looking statements" including without limitation statements regarding the demand for, future market penetration and market acceptance of BeIA and BeOS, the shipment dates of Be's products, and the future operating results of Be Incorporated. Actual events or results may differ materially as a result of risks facing Be Incorporated or actual results differing from the assumptions underlying such statements. Such risks and assumptions include, but are not limited to, risks related to competition, market acceptance and market penetration of Be's products, ability to establish and maintain strategic relationships, the benefit of Be's products to OEM and Internet appliance manufacturers. the continued availability of third party BeOS applications and drivers, and the ability to establish and maintain strategic publishing relationships. All forward-looking statements are expressly qualified in their entirety by the "Risk Factors" and other cautionary statements included in Be Incorporated's Annual Report on Form 10-K for the year ended December 31, 1999, and other public filings with the Securities and Exchange Commission. The BMessage Copyright (c) 2001 by Be, Inc. All rights reserved. Be, Inc. 800 El Camino Real, Suite 400 Menlo Park, CA 94025 Tel: (650) 462-4100 Fax: (650) 462-4129 Web: http://www.be.com/ Be, BeOS and BeIA are trademarks or registered trademarks of Be Incorporated in the United States and other countries. Other brand product names are registered trademarks or trademarks of their respective holders. All rights reserved. The BMessage is sent to subscribers of one or more of the Be mailing lists. For more information about subscribing/unsubscribing, see the Be web site: http://www.be.com/world/mailinglists.html. The Be web site also offers a complete set of current and back issues of Be Newsletters: If you have any comments about The BMessage, please e-mail them to:newsletter@be.com.

About Be, Inc. | Be Products | World of Be | BeOS Support | Jobs | Developers | Press | Partners | Investors

Copyright © 2001 by Be, Inc. All rights reserved. (Legal Info)
Comments, questions, or confessions about our site? Please write the Webmaster!