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: yo...@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-boun...@linux.intel.com [mailto:yocto-boun...@linux.intel.com] On Behalf Of Lock, Joshua Sent: Thursday, April 21, 2011 12:14 AM To: yo...@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 _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
