Post Reply 
Key pressing slows down program execution?
08-05-2018, 02:06 PM (This post was last modified: 08-05-2018 02:16 PM by komame.)
Post: #1
Key pressing slows down program execution?
Hi,

I noticed that pressing the keys slows down the program execution even if there is no check if any key was pressed.

Here is a simple example of drawing a color table and taking a time measurement of this drawing.
You need real hardware to perform this test.
I tried this on newest FW 2.0.0.13865 (2018 07 06).

Code:
EXPORT PERF_TEST()
BEGIN
 local tck,x,y;
 
 RECT_P(G0,#0); //clear screen

 REPEAT
  TICKS▶tck;
  //draw color table
  FOR x FROM 1 TO 38 DO
   FOR y FROM 1 TO 27 DO
    RECT_P(x*8,y*8,x*8+6,y*8+6,RGB(x*6,y*7,(x+y)*3));
   END;
  END;
  //get the time measurnment
  TICKS-tck▶tck;
  TEXTOUT_P(tck,G0,5,230,1,#FFFFFF,100,#0); //show the time
 UNTIL 0;

END;

My Prime shows about 260ms measurement in no key is pressed and about 330ms when pressed. Pressing the key slows down the program execution by 25% in this case. That's quite a lot of time considering the fact that the program does not even have a test for pressing a key.

What is the reason?

Piotr Kowalewski
Find all posts by this user
Quote this message in a reply
08-05-2018, 03:31 PM
Post: #2
RE: Key pressing slows down program execution?
(08-05-2018 02:06 PM)komame Wrote:  Hi,

I noticed that pressing the keys slows down the program execution even if there is no check if any key was pressed.

Here is a simple example of drawing a color table and taking a time measurement of this drawing.
You need real hardware to perform this test.
I tried this on newest FW 2.0.0.13865 (2018 07 06).

Code:
EXPORT PERF_TEST()
BEGIN
 local tck,x,y;
 
 RECT_P(G0,#0); //clear screen

 REPEAT
  TICKS▶tck;
  //draw color table
  FOR x FROM 1 TO 38 DO
   FOR y FROM 1 TO 27 DO
    RECT_P(x*8,y*8,x*8+6,y*8+6,RGB(x*6,y*7,(x+y)*3));
   END;
  END;
  //get the time measurnment
  TICKS-tck▶tck;
  TEXTOUT_P(tck,G0,5,230,1,#FFFFFF,100,#0); //show the time
 UNTIL 0;

END;

My Prime shows about 260ms measurement in no key is pressed and about 330ms when pressed. Pressing the key slows down the program execution by 25% in this case. That's quite a lot of time considering the fact that the program does not even have a test for pressing a key.

What is the reason?

Bonjour
Peut-être le fait qu'un programme peut être stoppé
avec la touche 'ON' et qu'il y a un test en ce sens lorsque une touche
est enclenchée.
Seulement un hypothèse.


Hello
Maybe the fact that a program can be stopped
with the key 'ON' and that there is a test in this sense when a key
is engaged.
Only a hypothesis.

Sorry for my english
Find all posts by this user
Quote this message in a reply
08-05-2018, 07:39 PM
Post: #3
RE: Key pressing slows down program execution?
(08-05-2018 03:31 PM)Tyann Wrote:  Maybe the fact that a program can be stopped
with the key 'ON' and that there is a test in this sense when a key
is engaged.
Only a hypothesis.

If it works the way you wrote, the ON-key test is always performed because even if key is not pressed the test has to be checked. But when the result of the test is 'false' (other key is pressed) it shouldn't be so much affecting the time of program execution.

Piotr Kowalewski
Find all posts by this user
Quote this message in a reply
08-06-2018, 01:09 AM (This post was last modified: 08-06-2018 01:10 AM by Tim Wessman.)
Post: #4
RE: Key pressing slows down program execution?
The slowdown isn't on the calculator code side due to any checking, but rather some poorly written OS behaviors and drivers that we don't have any ability to change. From memory, the keyboard driver spawns some threads, triggers some interrupts and runs on timers. Its a really poor design and implementation. Pressing a key triggers all sorts of behavior in the background that interrupts the main application thread and chews up time.

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
08-06-2018, 07:41 AM
Post: #5
RE: Key pressing slows down program execution?
Tim,

I just downgraded the FW to 10077 and now the program works faster (230ms while not pressing a key and 285ms while pressing).

Regardless of how internal OS keyboard handlers were written, you can see that in FW 10077, the programs were executed faster.

I also wrote about it in this thread about my game two years ago after upgrading to FW 10637, when I noticed a significant decrease in performance compared to FW 10077.
http://www.hpmuseum.org/forum/thread-4841.html
In FW 10637 were problems with the flow of animation during the key pressing that did not occurs in version 10077.

I think that there is still the possibility of improving something and speeding up the execution of programs (even while the keys are not pressed) since in earlier FW they were executed faster.

Piotr Kowalewski
Find all posts by this user
Quote this message in a reply
08-06-2018, 05:00 PM
Post: #6
RE: Key pressing slows down program execution?
(08-06-2018 01:09 AM)Tim Wessman Wrote:  The slowdown isn't on the calculator code side due to any checking, but rather some poorly written OS behaviors and drivers that we don't have any ability to change.

Why would HP use an OS over which they have no control? Seems risky to me.

Tom L
Cui bono?
Find all posts by this user
Quote this message in a reply
08-06-2018, 07:22 PM (This post was last modified: 08-06-2018 07:29 PM by Steve Simpkin.)
Post: #7
RE: Key pressing slows down program execution?
(08-06-2018 05:00 PM)toml_12953 Wrote:  
(08-06-2018 01:09 AM)Tim Wessman Wrote:  The slowdown isn't on the calculator code side due to any checking, but rather some poorly written OS behaviors and drivers that we don't have any ability to change.

Why would HP use an OS over which they have no control? Seems risky to me.

Probably for the same reasons that most software developers use an OS, RTOS, TCP stack, memory manager, device driver or other software modules that were written by others on most moderate to complex projects. To save time and money in not having to write code for a task that has already been written and debugged. The tradeoff is that you often do not have control over how that code operates or any idiosyncrasies it may have. Even open source code may be difficult to modify depending on how it was written. In many cases you may have to accept the limitations of code written by others or perform workarounds to achieve the functionality/reliability you want. The other tradeoffs are the potential cost of licensing the software module/OS (which can be substantial) and the potential complexity of integrating it into your project.
Visit this user's website Find all posts by this user
Quote this message in a reply
08-07-2018, 06:05 AM
Post: #8
RE: Key pressing slows down program execution?
Hello,

"Why would HP use an OS over which they have no control? Seems risky to me."

As you know, the Prime is manufactured by a 3rd party company called Besta.

Besta is more known for a then typical asian products "digital dictionaries/translators". And this is where Prime HW and OS originated.

What we did was put HP "calcualtor" application on top of a modified Besta dictionary and OS.

Doing so saves a lot of time as you reuse existing/working HW and SW.

So, here is the answer to the why.

Cyrille

Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 2 Guest(s)