In writing my datalog application, I have found that while the screen updates are slow, it's writing to a DB that really takes up time. In my app I get about 70 bytes of data a second over the serial port. At first I was writing a record every 5 to 10 bytes. You could see a noticable pause in the data and the datarate would drop significantly. I still update the screen after every byte, but now I que the data and only write a record once a second. And even then you can see a gap in the data collected but it's much better. I also leave the database open the whole time.
Fortunately, the data I was collecting was time based, not transaction based. So I just stored data for the previous second in one record. I think changing how often you actually write to the DB will help a lot with your speed problems. -Mike "Dave Mottorn" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I'm writing an inventory counting application that uses a custom keypad. > The custom keypad has very large tactile keys that allows auditors to enter > data as fast as they can move their fingers. They fastest guys enter data > faster than you would probably believe. Each time a transaction is entered > the program updates the screen with a history of the last 8 - 10 > transactions and running totals. Most of the screen is being rewritten with > every transaction. I'm using WinDrawChars to do the updates. > > The problem is the fastest auditors can get ahead of the screen updates. As > of a few weeks ago they could get so far ahead they would lose data. Since > then I changed the screen updates so a whole line is being written at a time > instead of portions of a line. I reduced the number of writes to the screen > to about a third of what they were and it made a noticeable difference. > Some of the auditors can still get ahead of the screen updates but they > don't seem to lose data now. > > I don't think I can do much to reduce the number of writes to the screen but > there are a few things I can do to make that part of the program more > efficient. I have the impression that writing to the screen consumes > overwhelmingly more time than my other inefficiencies and I wonder if it's > worth it to bother with them. Each transaction is written to a history file > which is opened and closed for each write. I could leave it open and > eliminate the open and close on each transaction. I'm also using a > push-down stack to keep numeric variables that represent the transactions. > I could use a circular stack and save a complete line of text for every > transaction. Then I wouldn't have to push it down and reformat it for every > transaction. My question is compared to the time it takes to write to the > display are these kinds of improvements going to make any difference? > > We're using Handera 330's at present but we're going to PDA's with faster > CPU's (probably Tungstens) in the murky future. Are we likely to see much > improvement in screen updates? My impression is that display technologies > aren't changing that much. > > Is there any way to increase the size of the keyboard buffer? > > The good news is that the auditors probably have a burst rate that's much > faster than their average rate for entering data. While they're entering > data for a single physical location they go very fast but when they have to > change locations they slow down. > > I'd appreciate hearing about any specific observations any of you have had > on these issues. > > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
