belliottsmith commented on code in PR #1891:
URL: https://github.com/apache/cassandra/pull/1891#discussion_r1105731270
##########
src/java/org/apache/cassandra/db/DeletionTime.java:
##########
@@ -38,14 +41,15 @@ public class DeletionTime implements
Comparable<DeletionTime>, IMeasurableMemory
/**
* A special DeletionTime that signifies that there is no top-level (row)
tombstone.
*/
- public static final DeletionTime LIVE = new DeletionTime(Long.MIN_VALUE,
Integer.MAX_VALUE);
+ public static final DeletionTime LIVE = new DeletionTime(Long.MIN_VALUE,
Long.MAX_VALUE);
public static final Serializer serializer = new Serializer();
+ public static final Serializer legacySerializer = new LegacySerializer();
private final long markedForDeleteAt;
- private final int localDeletionTime;
+ private final long localDeletionTime;
Review Comment:
It really shouldn't. The cast is free, you just load into a suitably sized
register. The truncation will have a single cycle latency (and greater than
one-per-cycle throughput). If you can measure the impact of this in a real C*
trace, I will eat my hat. If you can even get it to show up in a microbenchmark
that does _anything_ real (compaction, memtable read or anything really) I will
be very impressed. It's going to be 100% swallowed up by memory latency, data
dependencies in the pipeline, etc. You only worry about this kind of thing if
you can get far better instructions-per-cycle than we can. This is the lowest
of low level optimisation concern.
However, the wasted memory will definitely have an impact. For many JVMs
this will require an extra 8-bytes of memory.
So this is a pretty simple tradeoff, and I would not personally waste my
time benchmarking it. Software engineering is about picking your battles and
where your time is spent, and this is a bad battle to pick! But YMMV of course.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
