You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a minor issue that is only really a problem for large bundles (e.g. Xcode).
Currently, bundle hashing uses the subpathsOfDirectoryAtPath:error: API to get the list of files that need to be enumerated. This has some nice properties such as being able to know the count of files to process ahead of time. However the major drawback is that all paths must first be realized. For large bundles, such as Xcode, this can lead to a massive number of items (e.g. >140K).
We should instead consider the API enumeratorAtURL:includingPropertiesForKeys:options:errorHandler: to have better memory characteristics.
The major drawback with the new API is not knowing the number of files to process ahead of time which affects the progress bar status. This would have to be recomputed in a new way.
The text was updated successfully, but these errors were encountered:
This is a minor issue that is only really a problem for large bundles (e.g. Xcode).
Currently, bundle hashing uses the
subpathsOfDirectoryAtPath:error:
API to get the list of files that need to be enumerated. This has some nice properties such as being able to know the count of files to process ahead of time. However the major drawback is that all paths must first be realized. For large bundles, such as Xcode, this can lead to a massive number of items (e.g. >140K).We should instead consider the API
enumeratorAtURL:includingPropertiesForKeys:options:errorHandler:
to have better memory characteristics.The major drawback with the new API is not knowing the number of files to process ahead of time which affects the progress bar status. This would have to be recomputed in a new way.
The text was updated successfully, but these errors were encountered: