Well, I've got you both beat on the old-timer stuff. How about writing interrupt handlers to set bits to indicate which hammers should fire to print characters at the current position of the print drum of an IBM 1132 printer? In assembler, on punch cards.
Yeah, I've done the C and VMS thing, too. Anyway -- threads are what's scheduled, really, not processes. That is, only one thread can be executing in one processor core at once. How "fairness" is handled is another story, and processes do come into play at that level, but if you're running flat out, the only way to go faster is to either make your code more efficient, or to use threads to run on multiple cores simultaneously. Most Android devices only have a single processor core on the main processor. so another thread won't help you at all -- whether it's in the same process or a different process. It can even make it slower, due to interlocking overhead. HOWEVER, that assumes that you're actually using the processor full time. If you're sometimes waiting for the graphics processor, and sometimes waiting for the audio source, then eliminating these waits would speed things up. So, for example, you might have one thread that reads samples, and as soon as it has them, does the filtering operation, and hands it off to a display thread, which computes the graphics and pushes it to the display. Or, given your numbers, I think perhaps driving it from the other end -- one thread simply pulls in the samples, and the other thread grabs the latest sample, filters, and displays it. If you pull in a sample before the display side grabs it, you'd just replace it with the latest. This would save you the 100 ms on the front side. However, if you want bigger savings you'll have to go where the time is. You'll have to make the filtering faster. Either a more efficient filtering algorithm, or move to the NDK. On Apr 21, 9:03 pm, JP <[email protected]> wrote: > Old VMS guy here. > Threads are contained within a single process, i.e. not scheduled > separately. > Let me point out to things you could check out. First, the NDK could > help you on the performance side. > Second, if you want to run an activity in a separate process, use the > android:process=":<activity name>" > tag (this is set in AndroidManifest.xml). This will launch an activity > as a separate process (i.e. will show as a separate process when you > run a # ps) > > On Apr 21, 8:15 pm, BobG <[email protected]> wrote: > > > > > > > I have this audio analyzer app that fills a buffer with audiorecord, > > runs it thru a bunch of filters, and plots the filter out as a bunch > > of vertical bars. I timed the sampling, filtering and drawing with > > systemTimeMillis and it takes about 100ms,900ms and 50ms. I cant see > > how putting the calcs in another thread could speed it up any, but I'm > > just an old embedded c programmer. I guess linux is ticking every > > millisecond, and there must be a dozen linux tasks running, and I > > guess a task has a 'quantum' of ticks that it runs before linux > > preempts it (anyone know about these details?), but I just want it to > > run about 5 or 10 times faster. Appreciate any hints, tips, tricks, > > etc. > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group > > athttp://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group > athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
