cqlengine: Remove deepcopy on UserType deserialization

[k0machi]

This change makes it so newly instanced UserType during deserialization
isn't immediately copied by deepcopy, which could cause huge slowdown if
that UserType contains a lot of data or nested UserTypes, in which case the
deepcopy calls would cascade as each to_python call would eventually clone
parts of source object. As there isn't a lot of information on why this
deepcopy is here in the first place this change could potentially break
something. Running integration tests against this commit does not produce
regressions, so this call looks safe to remove, but I'm leaving this
warning here for the future reference.

Fixes#152

[Lorak-mmk]

Do you think you could open this PR against upstream too (datastax/python-driver)? I'd like to see if they see any reason not to merge this.

[fruch]

Do you think you could open this PR against upstream too (datastax/python-driver)? I'd like to see if they see any reason not to merge this.

FYI, no one responded on the issue that was opened:
https://datastax-oss.atlassian.net/browse/PYTHON-1309

[k0machi]

Opened in upstream: apache#1192

[fruch]

@Lorak-mmk

There was no response from upstream people yet

I'd say we will merge this performance improvement, since our testing didn't show it breaking anything.

[mykaul]

@Lorak-mmk

There was no response from upstream people yet

I'd say we will merge this performance improvement, since our testing didn't show it breaking anything.

• Speed bottleneck on deepcopy #152 (comment) mentions that several tests have failed.
• Do we happen to have performance numbers for this change?

[fruch]

@Lorak-mmk
There was no response from upstream people yet
I'd say we will merge this performance improvement, since our testing didn't show it breaking anything.

• Speed bottleneck on deepcopy #152 (comment) mentions that several tests have failed.

@k0machi was talking about other places there a deepcopy, he wanted to remove, not this PR

• Do we happen to have performance numbers for this change?

@k0machi did a manual test, with Argus calls, and shown a big improvement across the board.

we don't have a specific performance suite for this driver, especially not for cqlengine.

[mykaul]

we don't have a specific performance suite for this driver, especially not for cqlengine.

A before/after would hopefully suffice, showing reduced latency (I've seen elsewhere in the threads a reduction of seconds - #152 (comment) ?)

[k0machi]

we don't have a specific performance suite for this driver, especially not for cqlengine.

A before/after would hopefully suffice, showing reduced latency (I've seen elsewhere in the threads a reduction of seconds - #152 (comment) ?)

• Before
  

• After
  

It doesn't quite show the latency numbers, but this request went down from ~9s avg to 750ms average

[mykaul]

this request went down from ~9s avg to 750ms average

Thanks - this is what I was hoping to see. Flamegraphs are great, but perf results are more important.

[fruch]

Based on the information we do have, I think it's safe enough to merge
And it improve perf in quite a lot

[mykaul]

I believe we have a release pending this week - if so, I'd wait after the release, instead of sending it in the last minute.

[mykaul]

@avelanarius - can we merge it? The lack of response from usptream is disappointing, but should not hold us back.