byungnam opened a new issue, #4274: URL: https://github.com/apache/amoro/issues/4274
### Search before asking - [x] I have searched in the [issues](https://github.com/apache/amoro/issues?q=is%3Aissue) and found no similar issues. ### What would you like to be improved? `CombinedDeleteFilter` builds a per-file position-delete predicate. For every record it looks up the file path in `positionMap` and, when a `Roaring64Bitmap` is present, checks `posSet.isEmpty()` before `posSet.contains(...)`: ```java Roaring64Bitmap posSet = positionMap.get(structLikeForDelete.filePath()); if (posSet == null || posSet.isEmpty()) { return false; } return posSet.contains(structLikeForDelete.getPosition()); ``` The `isEmpty()` call is redundant and wastes CPU on the hot path (invoked once per scanned record): 1. Entries in `positionMap` are only created via `computeIfAbsent(...).add(...)` while reading position-delete files, so any value stored in the map is guaranteed to be a **non-empty** `Roaring64Bitmap`. `positionMap.get(...)` therefore returns either `null` (key absent) or a non-empty bitmap — never an empty one. The `isEmpty()` branch can never be true. 2. `Roaring64Bitmap.isEmpty()` is implemented on top of `getLongCardinality()`, which iterates over the whole set of high-to-low containers. It is not a cheap O(1) check, so paying it once per record is a measurable overhead on tables with large position-delete sets. ### How should we improve? Drop the `isEmpty()` check and keep only the null guard: ```java if (posSet == null) { return false; } ``` Behavior is unchanged (the removed branch was unreachable given how `positionMap` is populated) while eliminating a per-record `getLongCardinality()` traversal. ### Are you willing to submit PR? - [x] Yes I am willing to submit a PR! ### Subtasks _No response_ ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
