[yocto] [Yocto] discussion about bug770: Add mechanism to enable UI's to request extra data be stored in the cache

Zhang, Jessica jessica.zhang at intel.com
Wed Apr 20 09:28:43 PDT 2011


We had an earlier discussion with RP and per his suggestion, we're looking into the option of having a UI cache file that only contains the extra fields the UI is needed...

On Wed, 2011-04-20 at 16:34 +0800, Ke, Liping wrote:
> Hi, Jessica and Josh
>
> After looking into the cache.py, as well as the bug 770 description, I have following questions:
>
> 1. Valid Cache Problem: we only have one cache file, right?
> Use scenario 1: If developer firstly use ui mode, and then non-ui mode, the cache file should be valid? No need to update?
> Use Scenario 2: If developer firstly use non-ui mode, and then ui mode, the cache file should be invalid, need to update cache?
> Use Scenario 3: If developer firstly use ui mode, and then non-ui mode, and then ui mode, the cache file should be valid too?
> So we need to track the ui/non-ui ops machine to track the three different state (ui)-> <-(non-ui)?

Right now we only have one cache file, but in the bug report you'll see
a comment I pasted from IRC where RP suggests we might have ui specific
caches. Your analysis here emphasises that as a valid technique to
investigate.

>
> Option 1: update cache, modify cache invalidation mechanism (currently depend on mtime), it will surely cause the performance decreased if user switch from ui/non-ui mode
> Option 2: two different cache files? Loading them according to ui or non-ui mode , no need to invalid cache?

Well, the ui-specific caches would still need to be invalidated in the
same way that the current cache is.

>
>
> 2. Modify RecipeInfo data structure , static namedtuple could not be
> used, a dynamic dictionary will be used of course. It might cause
> performance decrease too according to Qing's input.
>
>
> My question is :
> 1. we will sacrifice parsing performance for the cache file size gain

I think we'd have to have a reasonable idea of how much of a performance
hit this would cause before ruling it out. I couldn't offer an answer to
this without writing some code and doing some benchmarking.

> 2. We will choose option 1, change cache invalid mechanism? I guess?
>
>
> I am not sure whether I am in the right track? Any comments?

You are definitely on the right track, I think this discussion would
benefit from public discussion though (that way Chris Larson (kergoth)
could be involved also).

Cheers,
Joshua
--
Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Centre




More information about the yocto mailing list