Libzypp/Design/Pointer

> Bir kez daha düşündüm: IMO, En azından bellekteki ilk dilin çevirilerini saklamalıyız.
> Eğer bunu yapmazsak dizgi'nin gerekli olduğu her seferde XML dosyasının tümünü sadece bir dizgi elde etmek için tekrar tekrar ayrıştırmak zorunda olacaktık.
> time a string is requested, we'd have to parse the XML file completely
> (eg. primary.xml) just to get one string, again and again.

Yes, that's why we wanted to check, whether it's possible to retrieve the position of data items in the xml file while parsing it. Remembering the position, later jump to it and just read the data.

> As we have to parser it on startup anyway, all the strings get into memory,
> so I guess that strings for the primary language should be either kept, or
> stored to disk in any other form in which it will be cheaper to get them later.

There are 2 problems, and we have to agree on how we're going to solve them.

= Concepts we implement and use or don't use within the library.

Well, a common concept takes a bit more time too be implemented, than a quick hack which can be easily distributed via cut&paste.

But it (hopefully) pays in the future, when you're able to refine the concept. You don't want to change a couple of code locations you once created by cut&paste, if you find out, that there is need for some conceptual change.

IMO we're not yet at the point to care about performance. We have to care about structure and concepts. If we happen to gain structure and concepts, we can gain performance much easier, than with a couple of individual solutions for common problems.

Q: Are we heading for such a kind of Helper class, and are we willing to use it at any point it applies - despite of possible performance penalties?

It may be possible to generalize the concept further, so it could be possible to have arbitrary conditions defining when to refresh the cached data, and when to cache at all (translatable values on locale change, filelists on high memory or if current rpm is accessible without media change,.. )

Caching is a common problem. The data handling classes are a good point to implement it. But they are not that good in deciding whether or not or howto do it (locale change, media availability, that's all stuff outside the data handling classes scope).

Offer the ability to cache but leave the decision to do so to someone else. Do we do or don't we do?

It's at first just the decision whether to create some class for this purpose, which everybody is then expected to use as it is. Not trying to implement local workarounds around shortcomings in the class. Just reporting them, so they are to be solved.

= XML as data format is either not performant or memory consuming.

That's a problem of XML and parser, not of our data classes. One solution to this could be that the parser is able to provide more information about the location of items in the xml file, enabling us to quick retrieve data, after we parsed the file, thus know the structure is ok.

This is to be solved in the xml parser. And if it will be solved, it influences the way the data retrieving functions ('label(locale)') can gain performance. This does not necessarily influence the way the retrieved data are stored in memory.

back

Last edit in Trac '11/24/05 18:54:44' by 'kkaempf'