[
https://issues.apache.org/jira/browse/YUNIKORN-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729399#comment-17729399
]
Craig Condit edited comment on YUNIKORN-1784 at 6/5/23 6:25 PM:
----------------------------------------------------------------
There's a tradeoff between potential performance improvements and ease of use /
code clarity. I don't think this one buys us enough to justify the additional
complexity and lack of API friendliness. We're talking about 16 bytes per
time.Time object vs. a 64-bit long. That's pretty insignificant. The largest
users of these would be the Allocation and AllocationAsk objects. Allocation
contains 3 time.Time fields while AllocationAsk currently contains 2. That's a
total potential savings of 16 bytes * 5 fields = 80 bytes per allocation (with
associated ask). Even with 100K active allocations, that's only 8 MB of memory
saved.
was (Author: ccondit):
There's a tradeoff between potential performance improvements and ease of use /
code clarity. I don't think this one buys us enough to justify the additional
complexity and lack of API friendliness. We're talking about ~ 8 bytes per
object where we track time. That's pretty insignificant; even with 100k active
allocations, that's still under 1 MB of memory used.
> Store time in int64 type instead of time.Time
> ---------------------------------------------
>
> Key: YUNIKORN-1784
> URL: https://issues.apache.org/jira/browse/YUNIKORN-1784
> Project: Apache YuniKorn
> Issue Type: Sub-task
> Components: core - scheduler
> Reporter: Peter Bacsko
> Assignee: Peter Bacsko
> Priority: Minor
>
> In various places in Yunikorn, we store time like:
> Application:
> {noformat}
> SubmissionTime time.Time
> finishedTime time.Time
> startTime time.Time
> {noformat}
> AllocationLogEntry:
> {noformat}
> LastOccurrence time.Time
> {noformat}
> AllocationAsk:
> {noformat}
> createTime time.Time
> {noformat}
> In the DAO objects, we convert it back to int64 with {{{}Time.UnixNano(){}}}.
> There are calculations at various places (eg. {{Since()}}, {{Sub()}}), but
> that's simple to solve.
> Storing a simple int64 is better because not only it consumes less space,
> {{time.Time}} also contains a pointer to a {{Location}} structure which we
> don't use.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
