<div class="gmail_quote">On Fri, Jul 9, 2010 at 2:14 AM, Piotr Galiszewski <span dir="ltr"><<a href="mailto:piotr@galiszewski.pl">piotr@galiszewski.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">2010/7/9 Daniel Burrows <<a href="mailto:dburrows@google.com">dburrows@google.com</a>>:<br>
</div><div class="im">> These are the ways of retrieving package information from a package </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<div class="h5">> that spring to mind immediately:<br>
> 1) Fully eager: as soon as the Package is created, copy all the values<br>
> from<br>
> the PkgIterator over into the Package object (I believe the GTK+ code<br>
> effectively does this).<br>
> 2) Fully lazy: the first time a member of Package is accessed, copy all<br>
> the<br>
> values from the PkgIterator into it (what the current Qt code does).<br>
> 3) Memberwise lazy without caching: just store a PkgIterator; when a<br>
> component of the Package is requested, return the corresponding<br>
> member of the PkgIterator (what the curses frontend does).<br>
> 4) Memberwise lazy with caching: when a component of the Package is<br>
> requested, copy the corresponding member of the PkgIterator into the<br>
> Package object and return it (I don't think any aptitude code does<br>
> this).<br>
> Which of these did you try? Do you have numbers showing how big an<br>
> improvement you saw? Could you try some of the others to compare?<br>
<br>
</div></div>I tried second and third points. Do not have any hard numbers. My<br>
assumptions were only based on feeling and time of response from GUI.<br>
I do not know how to provide numbers, but I will try. </blockquote><div><br></div><div> I might just instrument the GUI to run whatever you're testing immediately</div><div>on startup, then exit, and use the "time" command to check how long it took.</div>
<div>An alternative, maybe better, would be to save the system time before and</div><div>after the process you're interested in and log it (say, using LOG_()).</div><div><br></div><div> When I'm timing stuff like this I generally run it twice to eliminate cache</div>
<div>effects (the time on an empty cache is somewhat interesting, but I think</div><div>that normally a user of the GUI interface will have the package database</div><div>cached).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The speed was<br>
the easiest to observe during sorting and searching packages. On the<br>
other hand, I think that returning of the most members will be short.<br>
Only description loading and maybe something more is time consuming. I<br>
will experiment with this<br></blockquote><div><br></div><div> My main concern is that I don't want to get a bunch of complicated</div><div>code to optimize something that doesn't need to be optimized. But then,</div>
<div>maybe it'll turn out that it does need to be optimized after all...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> Is there any way to lose the QFoo types in Package? I'm not sure we<br>
> want to reuse it directly, but there might be a way to solve this problem<br>
> more generally, as long as it doesn't require the use of Qt-specific (or<br>
> GTK-specific) types.<br>
<br>
</div>Yes. There are only QStrings and QStringLists. std::string and<br>
std::list could also be used. Moreover, I think that this class<br>
requires much more thinking. Maybe it will be better do extend<br>
PackageInformation class (and rename this to package_information or<br>
package ;) ) ?</blockquote><div><br></div><div> Yeah, that could be a better place to start.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">There is also one more problem I am not entirely sure<br>
hot is should be solved. What should be done after cache updating?<br>
Packages could be changed so the state of package class also should be<br>
updated. Maybe package objects should be stored in map/hashtable in<br>
packages_pool instead of simple list?</blockquote><div><br></div><div> You need to deal both with changes to package state, and with the</div><div>whole cache being discarded and reloaded.</div><div><br></div><div> For changes to package state, you need some sort of map from</div>
<div>package iterators to objects in your GUI model. The backend supplies</div><div>you with a set of packages whose state has changed, and you just</div><div>need to find them and update them. In the GTK+ code, this is a map</div>
<div>from packages to iterators in the GTK+ tree model (we use a stock</div><div>one). If you're responsible for storing your own list, I'd recommend</div><div>using boost::multi_index_container for this case (one index for the</div>
<div>display order of the elements, another for finding elements by package</div><div>iterator).</div><div><br></div><div> In the GTK+ and curses frontends, we deal with the cache being</div><div>reloaded by throwing away all the currently displayed packages</div>
<div>and rebuilding the view from scratch. The only real alternative would</div><div>be to somehow merge the new cache into the display, maybe on the</div><div>basis of name and/or version strings? I don't think it's worth the</div>
<div>trouble for your first version.<br><br></div><div> Daniel</div></div>