[
https://issues.apache.org/jira/browse/ARROW-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16426774#comment-16426774
]
Dimitri Vorona edited comment on ARROW-2400 at 4/5/18 11:47 AM:
----------------------------------------------------------------
Hi Antoine,
this is something I've noticed before, but didn't find any time to investigate.
To localize the problem I've created a gist:
[https://gist.github.com/alendit/73ec62887d00fb44ef32e8f8eec41af3]
I get similar numbers to yours (both with -O3):
clang++ version 6.0.0
{noformat}
Run on (4 X 3200 MHz CPU s)
2018-04-05 13:29:13
--------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------
BM_ArrowStatus 885 ns 878 ns 735896
BM_OwnCopyStatus 897 ns 893 ns 780257
BM_NoOpStatus 884 ns 879 ns 785719{noformat}
g++ 7.3.1
{noformat}
Run on (4 X 3200 MHz CPU s)
2018-04-05 13:29:28
--------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------
BM_ArrowStatus 818 ns 813 ns 799285
BM_OwnCopyStatus 865 ns 855 ns 785573
BM_NoOpStatus 423 ns 421 ns 1734452{noformat}
So apparently there is an optimization which GCC can perform if the destructor
is strictly noop. I'd have to test further to localize the problem. A look into
the generated code might be worth it.
Cheers!
was (Author: alendit):
Hi Antoine,
this is something I've noticed before, but didn't find any time to investigate.
To localize the problem I've created a gist:
[https://gist.github.com/alendit/73ec62887d00fb44ef32e8f8eec41af3]
I get similar numbers to yours (both with -O3):
clang++ version 6.0.0
{quote}{{Run on (4 X 3200 MHz CPU s)}}
{{2018-04-05 13:29:13}}
{{--------------------------------------------------------}}
{{Benchmark Time CPU Iterations}}
{{--------------------------------------------------------}}
{{BM_ArrowStatus 885 ns 878 ns 735896}}
{{BM_OwnCopyStatus 897 ns 893 ns 780257}}
{{BM_NoOpStatus 884 ns 879 ns 785719}}
{quote}
g++ 7.3.1
{quote}{{Run on (4 X 3200 MHz CPU s)}}
{{2018-04-05 13:29:28}}
{{--------------------------------------------------------}}
{{Benchmark Time CPU Iterations}}
{{--------------------------------------------------------}}
{{BM_ArrowStatus 818 ns 813 ns 799285}}
{{BM_OwnCopyStatus 865 ns 855 ns 785573}}
{{BM_NoOpStatus 423 ns 421 ns 1734452}}
{quote}
So apparently there is an optimization which GCC can perform if the destructor
is strictly noop. I'd have to test further to localize the problem. A look into
the generated code might be worth it.
Cheers!
> [C++] Status destructor is expensive
> ------------------------------------
>
> Key: ARROW-2400
> URL: https://issues.apache.org/jira/browse/ARROW-2400
> Project: Apache Arrow
> Issue Type: Improvement
> Affects Versions: 0.9.0
> Reporter: Antoine Pitrou
> Priority: Major
>
> Let's take the following micro-benchmark (in Python):
> {code:bash}
> $ python -m timeit -s "import pyarrow as pa; data = [b'xx' for i in
> range(10000)]" "pa.array(data, type=pa.binary())"
> 1000 loops, best of 3: 784 usec per loop
> {code}
> If I replace the Status destructor with a no-op:
> {code:c++}
> ~Status() { }
> {code}
> then the benchmark result becomes:
> {code:bash}
> $ python -m timeit -s "import pyarrow as pa; data = [b'xx' for i in
> range(10000)]" "pa.array(data, type=pa.binary())"
> 1000 loops, best of 3: 561 usec per loop
> {code}
> This is almost a 30% win. I get similar results on the conversion benchmarks
> in the benchmark suite.
> I'm unsure about the explanation. In the common case, {{delete _state}}
> should be extremely fast, since the state is NULL. Yet, it seems it adds
> significant overhead. Perhaps because of exception handling?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
