[cfe-dev] PCHReader: Header search info and FileManager::NextFileUID

Douglas Gregor dgregor at apple.com
Mon Jun 8 07:46:40 PDT 2009


On Jun 8, 2009, at 2:08 AM, Zhongxing Xu wrote:

> 2009/6/8 Douglas Gregor <dgregor at apple.com>:
>>
>> On Jun 7, 2009, at 10:48 PM, Zhongxing Xu wrote:
>>
>>> 2009/6/8 Zhongxing Xu <xuzhongxing at gmail.com>:
>>>>
>>>> Hi,
>>>>
>>>> After HeaderSearchInfo is recovered in
>>>> PCHReader::ReadSourceManagerBlock(), we actually have used some  
>>>> UIDs
>>>> (recorded by NumHeaderInfos). But at this time the NextFileUID in
>>>> FileManager is still 0. Call to FileManager::getFile() could use  
>>>> that
>>>> FileUID for a different file than the header in HeaderSearch. Would
>>>> this inconsistency cause problems?
>>>
>>> After reading some more code, my understanding is that all file  
>>> source
>>> locations are then preloaded and FileManager is restored to the
>>> appropriate state.
>>
>> Yes, we preload all file source locations. We may be able to  
>> decrease PCH
>> load times slightly by not preloading them, but it's not something  
>> that ever
>> came up in a profile so I doubt it's important.
>
> I think we have to preload them to bind the correct UIDs to the header
> files? Otherwise FileManager may use UIDs for different files than the
> files in HeaderSearchInfo.


This probably means another level of mapping between PCH UIDs and the  
current UIDs, if we want to avoid preloading.

	- Doug



More information about the cfe-dev mailing list