Brock Pytlik wrote: > Bart Smaalders wrote: >> Michal Pryc wrote: >> >>> Hi, >>> I have already asked about this few months back: >>> http://mail.opensolaris.org/pipermail/pkg-discuss/2008-March/002217.html >>> >>> There is an script which shows how the description are taken from the >>> manifest file. To get GUI up and running we need to have descriptions >>> for *all* packages, so currently this is quite long task, more then that >>> this is even longer if the manifests are not in the local catalog. >>> >>> The acceptable time for such option would be less then 1 seconds which >>> is far from what is now. Currently each time user starts GUI the number >>> of opened manifest files is the number of all packages, just to get >>> description, that is why I think (I might be wrong) that caching this >>> kind of information will give huge performance improvement. >>> >>> If you have any other suggestions I would be very happy to go other then >>> caching way. >>> >>> The bug 243 should cover this as Danek wrote in that thread: >>> http://defect.opensolaris.org/bz/show_bug.cgi?id=243 >>> >>> I am attaching dtrace script which shows opened and written files (O/W) >>> running this script together with the script attached in the e-mail >>> from March would give information how much files needs to be opened and >>> how slow is getting description information. >>> >>> ./print_changes.d /path/to/the/ips/catalog >>> >> >> Rather than caching, etc, I'd like to suggest that using the search >> mechanism to retrieve information is a better approach. >> >> This would allow for the quick retrieval of descriptions, icons, etc, >> from current or new repos. >> >> - Bart >> >> > I'm not sure how you're envisioning using the search mechanism to do > this. To my knowledge, search doesn't currently support getting the > description (for example) of a specific package. This wasn't a use case > for search which I had thought of so I'll have to consider whether the > new version of search would have the capacity to do this (at least if it > provides (or could provide) the data structures to make this efficient) > > Also, setting aside whether or not search could do this, isn't the cost > of transferring all of this information from a remote server on start up > each time prohibitive? Especially for things like icons, isn't that a > large amount of data to pull across the network given the time frame (< > 1 sec) we're considering? > > If I understand correctly, there are really two problems: pulling > information for all the local individual manifest files takes too long; > pulling the information for manifests not stored locally takes way too long. > > On the first, I suppose there's no reason (other than duplication of > data) not to gather this information and pkg install time and add it to > a central location. On the second, given that hitting the server seems > unavoidable to me (which means the 1sec constraint is likely to be > violated), perhaps what should be done is the program caches a small > subset of what it will need to retrieve from the server (which would > probably be gui dependent since different gui's might prioritize > different packages) then it can show the user the cached information > while it goes off and asks the server for updated information on those > packages and fills in the rest of its package descriptions. >
A small local cache is fine as a gui hack, but I'd much rather work towards a model of retrieving descriptions and icon pointers dynamically. The icons can be cached locally by hash. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
