-
Notifications
You must be signed in to change notification settings - Fork 18
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
Is anybody else dissatisfied with the general performance of ppl? #28
Comments
I haven't noticed any speed issues in most cases. This is on a generally slow machine with a regular drive:
Where I have noticed a little slowness is when using it in Mutt (when compared to abook).
|
I've checked the timing again a few minutes later, and the results are different. $ time ppl
real 0m1.186s
user 0m1.140s
sys 0m0.040s I've spent a little time poring over
In fact, if I replace the IniFile gem with IniParse, performance improves quite noticeably. $ time ppl
real 0m0.576s
user 0m0.524s
sys 0m0.048s
It's enough of a noticeable performance boost that I may just have to look into the feasibility of making this change permanent in a future version. |
Another good reason to move to IniParse is that it claims to be able to write changes to an INI file without disrupting the ordering of the contents or removing any comments. This could be instrumental in enabling the creation of a |
The change in |
I'm not sure if this is due to changes in
The above was done on the same machine as the previous statistics. |
I apologise for ignoring all your input for the last 23 days! I took on some new responsibilities at work and while I acclimatised to the new workload I didn't really feel like working on software in my free time. Anyways, yes, I agree: performance is nowhere near where it should be. I now think it's because of rubygems. I've been looking into other projects that use Ruby to power a CLI application, and they largely avoid rubygems for performance reasons. For example, Heroku:
Also, hub:
This is going to be my next avenue of enquiry in the quest for satisfactory performance. |
bump I have 350 addresses by now and am working on a 4 year old MacBook Pro.
I tried what would happen if I cut down my addressbook to less contacts (in the end it where 179)
I'm afraid that's simply to slow :( |
Man, I'm so sorry about this problem. I wish ppl's performance scaled better with address book size. But as I'm unlikely to undertake the significant reworking that would be necessary to fix this problem any time soon, I'm going to close this issue so that my issue queue only reflects new or ongoing issues. |
oh don't worry. so: at some time in the future I might have a little helper programm |
…ading This method was being call dozens of times per execution of ppl. Reading and parsing that INI file is an expensive series of operations, and this inefficiency was severely impacting ppl's performance. I actually measured a speed increase of almost an entire second because of this change. It's pretty shamefully bad performance in the first place, but at least this fixes that somewhat. This pretty much fixes #28, for now at least. Wow. Sorry everyone, I goofed on this one.
Hey,
Has anyone else out there found that ppl generally takes a few hundred milliseconds longer to execute than they'd like? I primarily use ppl on two different computers: one with an SSD, and one with a regular spinning platter hard-drive. Paradoxically, I find that ppl runs like a sick old horse on the machine with the SSD, and comparatively quickly on the one with the regular hard-drive.
Check out this fairly typical SSD running time:
That's almost two seconds! And it's just the plain
ppl
command which displays the help text! In fact, look what happens if I runppl ls
!Over two seconds! I'll amend this issue with some figures from the machine with the regular hard-drive as soon as possible, but in the meantime, is anybody else suffering with performance as poor as this?
The text was updated successfully, but these errors were encountered: