Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PDCurses on Plan9 works but is very slow ... how can I figure out what is wrong? #95

Closed
staalmannen opened this issue Jun 12, 2020 · 3 comments

Comments

@staalmannen
Copy link

Hi

I recently updated the old PDCurses port to latest git master and made a pull request #93 . As mentioned there, the demos and other curses-based programs I install work but are extremely slow (I first thought they were unresponsive).

CPU load not high (see picture attached) so I am guessing that it has something to do with time measurement and refresh rate or something?

How can I figure out what is wrong? I checked the file "refresh" under pdcurses/ but that did not make me any wiser unfortunately.

9front_pdcurses_demos

@Bill-Gray
Copy link
Contributor

Bill-Gray commented Jun 12, 2020

Hmmm... are you seeing a long wait and then bam, the screen is updated? Do lines appear one at a time? Or do you see the characters crawl across the screen (in, say, "PDCurses Test Program", can you watch as that particular text is updated?)

I know virtually nothing about Plan9. I do wonder about p9napms, wherein you call sleep(ms). On Linux, that would sleep for ms seconds, not milliseconds. Might be worth just commenting out that line and seeing if it suddenly roars to life (though with no sleep at all, you'll also see CPU load spike.)

EDIT: Plan9's implementation of sleep does use milliseconds. So it's not quite that easy...

@staalmannen
Copy link
Author

staalmannen commented Jun 12, 2020

It is more of the long wait then bam, not like slow line-by-line updates and no slow crawling text updates.

Indeed there is a difference between plan9 sleep and posix sleep. The problem here is that this is built under APE so sleep should be posix.... I will try that.

Edit: WOW commenting out the sleep did indeed make it blazing fast! Good catch! I will try to make a napms variant based on nanosleep() instead.

@staalmannen
Copy link
Author

Thanks for solving the issue! Good catch! Now I just need to figure out a proper way of doing the ms sleep. nanosleep() caused a crash.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants