Page 24 of 33 FirstFirst ... 141920212223242526272829 ... LastLast
Results 461 to 480 of 657
  1. #461  
    im getting 111 tics in 1 second and im not running a vanilla treo!
  2. #462  
    Yikes! I've read about SnapCalc but sheesh. With SnapCalc enabled, over 7700 tics and 70 secs, disabled I get 325 tics in 3 secs.
  3. #463  
    If you put SnapCalc in the command bar activation mode, it doesn't hook the event queue and won't cause slowdowns.

    The command bar isn't enabled by default on the Treo, but you can use FieldPlus or Butler to pop up the command bar. If you do use FieldPlus, use my modified version; the original version hooks the event queue in an inefficient way. (http://www.nekito.net/~sachs/palm)
  4. #464  
    doomsey,

    Thanks for the advice--and the program. I downloaded your FieldPlus, set SnapCalc to activate from the command bar and it works great. My speed test is 536 tics in 6 sec. Not as good as when SnapCalc is disabled but much, much better than with it activating using a hard button. Now that I have it, I may as well test out the text selection features.

    Just a question though: are there any settings of FieldPlus that are more or less efficient with regard to system resources?

    Also, has anyone noticed the speed test toggles the keyboard lights? Sorry, this is an afterthought, I'll search the thread too.
  5. #465  
    FieldPlus isn't really my application; I just patched it to lower the event-processing overhead.

    Athough there is a menu in FieldPlus to determine which applications FieldPlus is active in, one of the side effects of the patch is that disabling it in an application doesn't actually lower the event-processing overhead. It'll use pretty much the same amount of time to process an event no matter what you change.
  6. #466  
    Quote Originally Posted by stevengoh
    DBCacheTool does hook 'hede' & cause cosiderable slowdown to image intensive apps.

    For me, since I only use 'App stop' feature, not the 'Ctrl tap', I use the hex editor to
    nop the 'SysNotifyRegister' for 'hede' API in DBCacheTool.prc, & the speed test result
    figure is down by 40+.
    Could you explain this in more detail. What do you mean by nop? Which Hex editor did you use? What's the SysNotifyRegister?

    Thanks,

    Piri
  7. #467  
    Quote Originally Posted by piridongo
    Could you explain this in more detail. What do you mean by nop? Which Hex editor did you use? What's the SysNotifyRegister?

    Thanks,

    Piri
    You can use the free hex editor: frhed from www.kibria.de/frhed.html

    Open DBCacheTool.prc (ver 2.0a) in frhed, replace all occurances of 'hede'
    with 'none' (3 times) & save it. It will hook 'hede' no more.
  8. BenJoeM's Avatar
    Posts
    786 Posts
    Global Posts
    787 Global Posts
    #468  
    Quote Originally Posted by stevengoh
    You can use the free hex editor: frhed from www.kibria.de/frhed.html

    Open DBCacheTool.prc (ver 2.0a) in frhed, replace all occurances of 'hede'
    with 'none' (3 times) & save it. It will hook 'hede' no more.

    It is about time I tried this palm internals stuff! I have been running DBCache Tool for about 5 months now and seen a big change in stability, but after running palm internals I saw I was running and 4999 tics and 50 seconds. So Used the hex editor and fixed the hede, I am not at 4 seconds! WOW! I can already see my palm moving faster. This is a great thread
  9. #469  
    Is anyone getting:

    DBCache

    showing up as a line entry? Just that, no number in front of it. So therefore after ---hede--- I have:

    *100 'Qlaunch' m68k 7319240A
    DBCache
    *101 'Butler' m68k 731308CC
    DBCache
  10. #470  
    "DBCache" just got wrapped around on the screen - it's actually the end of the Butler line and shows that Butler has locked itself into the dbcache area.
  11. #471  
    Since this a popular thread can we get 1st message edited to include latest version (1.10.2) and link ?

    http://mytreo.net/downloads/details-...?PalmInternals
  12. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
       #472  
    Done. Thanks.
  13. tmt
    tmt is offline
    tmt's Avatar
    Posts
    84 Posts
    #473  
    Quote Originally Posted by tomvb2000
    ...shows that Butler has locked itself into the dbcache area.
    Actually all it shows is that Butler has requested a callback into the DBCache area. Whether that address is still within Butler or not depends on whether Butler locked itself there. To find that you have to look elsewhere.
  14. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
       #474  
    Is this working for the 700P?
  15. #475  
    Runs fine on the 700p, but Im not sure yet how to intrepret the results...
  16. #476  
    FWIW, I just installed it on my 700p and locked KeyCaps, FieldPlus, and HiLauncher (same as I did on my 650). Before locking anything the speed test came back with 5 seconds. After locking the resluts remained 5 seconds.

    Locking those apps on my 650 made a huge diffrence in speed, so maybe this isn't needed on the 700p or possibly PalmInternals or RLock needs to be changed somehow.
  17. #477  
    Locking just makes sure that the apps aren't flushed out of the dbcache when it gets low.. they are always going to be there. as a result they don't need to be loaded again and again (if flushed out), hence the increase in speed that you noticed.

    Also, locking and unlocking doesn't make a difference in the speed test of palmimternals, and actually it ain't supposed to do so either... so nothing wrong with either RLock or PI.
  18. #478  
    Quote Originally Posted by serious joe
    'To use PalmInternals to gauge the speed of an application or its impact on the overall performance of the Treo especially when it comes to HEDE is not really appropriate. Central will have zero noticeable impact on the Treo. HEDE is all about the use of the keyboard, if you are not using the keyboard it has minimal impact on the Treo performance at all. PalmInternals sends a large number of keyboard events to the queue and times how long it takes to process these events. This never happens in the real world. This should be made clear. It would take someone typing at 100 words per minute to notice any impact at all through Central's HEDE overhead. Even at this typing speed Central's impact would be barely noticeable.

    Why do some applications have a HEDE impact? Because Central has to check each key input as a part of its normal function. This takes far less than a thousandth of a second to do. Central runs in the background and so is always going to have a HEDE overhead. The main reason that Central and Butler show different timings is that Central launches favorites directly when a button is held down for two seconds. Butler launches the Phone application which then launches the favorite. Because we launch the favorite directly we have to check whether their is an actual favorite associated with the key. You may have noticed that even if there is no favorite assigned to a key Butler will still launch the Phone application.

    Finally if you believe that Central is impacting your Treo performance disable some of its functions. I will bet that it will not be the cause of your slow downs.'
    This explanation is somewhat disingenious.

    The problem with 'hede' is that if you register for it, then your app is called when every single event happens (not just key events). Unfortunately this is the only way to get key events (you have to filter them out and ignore the rest). Here is what the palm os reference says

    sysNotifyEventDequeuedEvent
    The sysNotifyEventDequeuedEvent is broadcast for each event
    removed from the event queue with EvtGetEvent.
    WARNING! Be very careful about registering for this notification;
    it can result in significantly degraded system performance.

    There are a LOT of events when anything happens - 6-8 when an app is launched for example, or about 3 for every keypress.

    If you are an app that needs to get key events (like Butler or Central) then the key is to handle events quickly - particularly ones where you don't want the event.

    There are two ways to respond to an event.
    1) call a function
    2) launch your app in the background to handle it

    1 is MUCH faster as the application doesn't need to be initiated, but this is the cause of problems with the cache on the 650. you have to be very careful that your app is where it said it would be when the notification calls the function. That's why apps have to lock themselves in cache.

    2 is safer and easier to code. The system loads your app into cache if needs be, then sends it the event to handle. However it is slower.

    Butler uses 1) for 'hede' which happens a lot (many times every second) and uses 2 for events that happen less often. You can see the difference in palm internals. The function calls have a note like m68k and a number.

    It looks like Central uses method 2 the whole time, though Im not 100% sure that I'm reading palm internals correctly on this.

    Finally, regarding the point of launching through the phone app. Central is being disingenious again. Butler hasn't launched apps through the phone app for a long time (calls and bookarks are still launched that way). Though I am proud to have been the first person to develop that functionality! Either way, this speed impact can only be relevant with a keylaunch.

    Finally the test: Although the key presses are not a perfect test, they are at least indicative of the time taken to handle events as they do make the system call the function which will be called for every single event.

    EDIT: Results updated!
    I just tested on my treo with central and butler. Engaging central, I engaged the keylauncher and got a result of
    7360 ticks
    Engaging Butler, I engaged all default features and got a result of
    4702 ticks
    Without Butler, or Central, I got
    4390

    Would be interested if anyone else could run the same test.


    ymmv.
    Last edited by confusedvorlon; 06/04/2006 at 04:10 PM.
    Hobbyist Software
    VLC Remote - Control VLC from your Pre
    Remote - Control iTunes from your Pre
  19. #479  
    Quote Originally Posted by confusedvorlon
    I just tested on my treo with central and butler. Engaging central, I engaged the keylauncher and got a result of
    7776 ticks
    Engaging Butler, I engaged all default features and got a result of
    4791 ticks
    Without Butler, or Central, I got
    4796

    I don't understand why butler would be speeding things up - but I guess it must be measuring error. Would be interested if anyone else could run the same test.
    ymmv.
    yupp... a measuring error it is, coz no matter how gr8 or indispensable an app butler may be, it sure ain't gonna speed up things

    here's the overload butler adds fo me:

    plain treo with no background apps:
    Time in tics 111, time in secs 1

    butler with defaults enabled (remains same even if u enable everything):
    Time in tics 373, time in secs 4

    you can enable as many other background apps as you want (hi-launcher, kblightsoff etc.., the butler overhead is gonna be the same.)

    the good thing about butler is that despite the minor overhead that it shows in palminternals, it is not noticable one tiny bit. try disabling butler and enabling it again and you'll see what i mean. there are a few other apps that cause a major slowdown, mainly when coming back to the phone app (pressing the green button), the white screen just tends to stay on for much longer.. not so with butler though.

    all said.. butler is a fabulous app, one that can't be done without!
  20. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
       #480  
    Quote Originally Posted by confusedvorlon
    Would be interested if anyone else could run the same test.ymmv.
    You couldn't pay me to put Butler back on my phone

Posting Permissions