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

[Ke, Liping]

Forward the mail to the proper mail list.

Discussions about adding extra cache file for caching extra fields requested by bitbake ui, in case you're interested -:)

criping

-----Original Message-----
From: Lock, Joshua 
Sent: Thursday, April 21, 2011 1:12 PM
To: yocto at linux.intel.com
Subject: RE: [Yocto] discussion about bug770: Add mechanism to enable UI's to request extra data be stored in the cache

Hi, Josh

Thanks for your quick response!

Yes, the mail should be to public mail list. I am just installing win7 and sys-configuration is still in a mess...

Yes, I will try ui-specific cache files for incremental cache fields storing. For doing this, I need to pass
Config.ui info into Cache class for referencing whether it is in ui mode. 

I found a strange function called def init(cooker) in cachy.py. Do you know what's this function for?
Since Cache class is instanced only twice, one in cooker and one in this init... I just want to make sure what this
def init is for.

Thanks a lot for your help!
criping



-----Original Message-----
From: yocto-bounces at linux.intel.com [mailto:yocto-bounces at linux.intel.com] On Behalf Of Lock, Joshua
Sent: Thursday, April 21, 2011 12:14 AM
To: yocto at linux.intel.com
Subject: Re: [Yocto] discussion about bug770: Add mechanism to enable UI's to request extra data be stored in the cache

Hi Liping,

Any reason this discussion couldn't be had on the public mailing list
(per Richard's recent email)?

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