You are not logged in.
Couldn't pacman hold two text files: one with names of all currently installed packages and second with all available packages. It could be used when simple:
pacman -Ss <name>
or
pacman -Q <name>
is entered by just greping them.
Currently this two common (for me and I think for other users too) actions runs so slowly and almost always fast output is needed - not big action.
Thanks.
jabber id: arael (at) fov (dot) pl
Offline
spreading similar info in more files increase the possibility of damage to the database.
Something that can make more powerful query and speed up the process is
http://sqlite.org/
It is a library that can handle sql query over text base database
Offline
spreading similar info in more files increase the possibility of damage to the database.
Yes, you are right of course. But this two function have only informative meaning - even some mistakes (that shouldn't happen) there wouldn't make big problems.
But... for security reasons maybe adding s (as from speedup - other letter would be good too) flag would be good. Then fast versions of those commands (using cached text files) would look like this:
pacman -Sss <name>
pacman -Qs <name>
What do you think?
jabber id: arael (at) fov (dot) pl
Offline
Try a couple of things out here...
Run 'time pacman -Ss text'. You should see that subsequent executions are faster because the pacman binary has been cached (and doesn't have to be read from the hard disk).
Realize also that pacman -Ss searches names and descriptions.
There may be a small increase in speed using a method like that. Maybe you could submit a patch .
You wouldn't have to worry about corrupt databases, because you could just regenerate them at any time, though all upgrades and removals would take a lot longer.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
I've figured out more precisely how this is all working and pacman isn't slow as I said - only the first search is. :oops: If only the first time could be faster. I'm wondering if this speed up in next "pacman -Q" or "pacman -Ss" is a result of cached binary or cached DB information.
Maybe my idea is not so meanfull, but this delay when running pacman is quite irritating. Maybe someday - when some developer will not have anything better to do...
Thanks and sorry.
jabber id: arael (at) fov (dot) pl
Offline
In the forum I "heard" of people having much better performance using reiserFS
Offline
The Pacman DB is just a bunch of many files, reading al those takes a while. It's not because of cached binaries...
On my old hd it takes about 11 seconds before results are displayed when I search for "test". I can live with that, because the next runs are very fast, and 11 seconds isn't that much.
I was thinking about a (autogenerated) DB which is used for all the searching and querying, but I'm not sure if it's worth the trouble. I'm also not sure which database to use, sqlite is rather big, perhaps tdb is good enough. I'll see how quick the searching is with Reiser4, and if it's still too slow then I may write a patch.
Offline