0

How does JavaScript represent strings and Date objects in memory?

Context and Intent

I'm mostly just curious, but here's what led to the question: We have code in our React front end that accepts JSON payloads from our API, and those payloads include dates -- in ISO-8601 UTC string form (e.g. 2023-02-01T17:01:08Z), of course.

As we pass the resulting model object around a variety of hooks, components, functions, etc., we keep it as a string, and we only parse it into a Date object if we are going to display it or use it to make decisions. In some cases, this means that we'll re-parse the same string into a Date multiple times in the course of rendering the UI. In other cases, we ignore the Date completely as it's not relevant for the page.

I'm trying to reason about whether it would be worthwhile to modify our system such that we always parse Date strings into actual Date objects upon receipt from our API. Our UI is written in TypeScript -- AFAIK this makes no difference with regard to my actual question -- and my biggest motivator in wanting to make this change is the improved type safety and clarity.

To be clear, time performance is the bigger concern, but I can do my own benchmarking. For the purposes of this question, I'm asking about memory performance, as much for my own understanding and education as for any technical decisions that might result, but I always try to understand the full scope of any tradeoff.

I imagine that this could be implementation dependent; if so, I'm most interested in the facts as they apply to modern versions of Google Chrome (with default configuration, if that matters), but happy to learn about other implementations as well.

Questions

If I take a 20-character ISO-8601 UTC string and parse it into a Date, how much memory would the resulting Date use? Does JavaScript work like Java, using an 8-byte "long" integer to store dates as milliseconds since the epoch? I found disappointingly little information about this in my searching; most of the results I found were actually about Java.

Also, how much memory does the string use? What's Javascript's internal string encoding? A quick Google indicates that it uses UTF-16 (and therefore 40 bytes for the 20-character date string)?

For both Date and String, are there any differences in applicable overhead? Are there optimizations that might apply to either Strings or Dates and affect the result (e.g. string interning -- which if I am understanding this correctly, JS does, but it would not apply to my use case since the value came from an API response)?

halfer
  • 19,824
  • 17
  • 99
  • 186
JakeRobb
  • 1,711
  • 1
  • 17
  • 32
  • *links to relevant specifications, source code* is out of scope for Stack Overflow. *Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam.* [What topics can I ask about here?](https://stackoverflow.com/help/on-topic) – Ole V.V. Feb 01 '23 at 19:58
  • 1
    [*ECMA-262*](https://262.ecma-international.org/#sec-overview-of-date-objects-and-definitions-of-abstract-operations) defines how *Date* are represented, the rest is implementation detail that is off–topic here. If the issue is performance, optimising based on such low level implementation detail is unlikely to produce consistent results and is likely premature optimisation. – RobG Feb 01 '23 at 22:21
  • 1
    I’m voting to close this question because it seeks implementation details that are unlikely to be helpful for optimising performance. – RobG Feb 01 '23 at 22:24
  • 1
    @OleV.V. I think my closing out my question with a note that I’d appreciate such links is quite different from it being the core of my question. – JakeRobb Feb 02 '23 at 21:48
  • 1
    @RobG, I adamantly disagree. Understanding how the tools we use actually work is important. To wit: every computer science curriculum includes a basis of understanding: logic gates, adders, compilers, operating systems, networking, and so on. If SO isn’t the place to ask about implementation details, then what is? – JakeRobb Feb 02 '23 at 21:54
  • @RobG thank you for the link. I believe I was clear that I am not asking in the context of performance or optimization (premature or otherwise), but because I seek a deeper understanding of how these things work. – JakeRobb Feb 02 '23 at 22:07
  • I thought "*To be clear, time performance is the bigger concern*" hinted at performance. Regardless of your motivation, unless implementation details are directly related to your question (e.g. how closures used to cause memory leaks in some browsers, why DOM elements don't use prototype inheritance in some browsers) they're off topic here. And in regard to performance, only benchmarking across a wide range of user agents will answer that (expect the unexpected!!). ;-) – RobG Feb 04 '23 at 01:43
  • You should read the rest of that sentence, and the rest of that paragraph. It’s the bigger concern, but I don’t need (and was not asking for) help testing it or understanding it. – JakeRobb Feb 04 '23 at 19:00
  • I see that I now have two votes to close -- both because I "seek implementation details unlikely to helpful for optimizing performance." Both voters have somehow misunderstood something I stated explicitly in the question: "I'm asking about _memory_ performance, as much for my own understanding and education as for any technical decisions that might result, but I always try to understand the full scope of any tradeoff." – JakeRobb Feb 12 '23 at 17:48
  • Pro tip: comments or in-question meta-commentary that sounds confrontational can attract close votes, even from readers who previously might have refrained from voting. It's worth being careful with phrasing if you can, even if you think you're right. There is a patch of grey-zone where topicality is probably a bit subjective. – halfer Feb 12 '23 at 18:30
  • That’s fair; thank you. I think I asked a perfectly reasonable and appropriate question, and because I’ve been around here long enough to know that my question could be misconstrued, I took care to state the things I’m NOT asking about — and yet those very things are being used as a reason to close. I feel like people are voting to close without actually reading my question, which, frankly, is insulting. Please accept my apologies for reacting confrontationally. – JakeRobb Feb 14 '23 at 03:47

0 Answers0