Github user JoshRosen commented on a diff in the pull request:
https://github.com/apache/spark/pull/16357#discussion_r93326959
--- Diff:
core/src/main/java/org/apache/spark/util/collection/unsafe/sort/UnsafeInMemorySorter.java
---
@@ -256,6 +259,14 @@ public boolean hasNext() {
@Override
public void loadNext() {
+ // Kill the task in case it has been marked as killed. This logic is
from
+ // InterruptibleIterator, but we inline it here instead of wrapping
the iterator in order
+ // to avoid performance overhead. This check is added here in
`loadNext()` instead of in
+ // `hasNext()` because it's technically possible for the caller to
be relying on
+ // `getNumRecords()` instead of `hasNext()` to know when to stop.
+ if (taskContext != null && taskContext.isInterrupted()) {
+ throw new TaskKilledException();
+ }
--- End diff --
In an admittedly non-scientific benchmark, I tried running
```
import org.apache.spark._
sc.parallelize(1 to (1000 * 1000 * 1000), 1).mapPartitions { iter =>
val tc = TaskContext.get()
iter.map { x =>
tc.isInterrupted()
x + 1
}
}.count()
```
a few times with and without the `tc.isInterrupted()` check and there
wasn't a measurable time difference in my environment. While I imagine that the
volatile read could incur some higher costs in certain circumstances I think
that the overhead of all of the virtual function calls and iterator interfaces,
etc. will mask any gains by optimizing this read.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
