0

Working with an object that seems to be too nested and that I want to hard-clone, I get a 

var copy = JSON.parse(JSON.stringify(big_object));
-> RangeError: Invalid string length for a too large string

I have workarounded it by cloning it while skipping the first nested layer

var copy = {};
for (o in big_object) {
    copy[o] = JSON.parse(JSON.stringify(big_object[o]));
}

But I am wondering what is this limit? In my case I get this error by doing the following:

var objs = {};
var objs.obj1 = JSON.parse(obj1);
var objs.obj2 = JSON.parse(obj2);
var objs.obj3 = JSON.parse(obj3);
var objs.obj4 = JSON.parse(obj4);
var objs.obj5 = JSON.parse(obj5);
....
var objs.obj6 = JSON.parse(objn);
....
var copy = JSON.parse(JSON.stringify(objs));

where obj1..n are JSON files of ~40 Mb each that the user decides to process. When I process 7 files, no problem. When I process 8 files, I get the error.

*The size is 1.9Gb, this hardly seems to be my case (see Is there a limit on the size of a string in JSON with Node.js?)

Community
  • 1
  • 1
GWorking
  • 4,011
  • 10
  • 49
  • 90
  • 3
    shallow or deep clone? – georg Sep 28 '16 at 13:55
  • 2
    Possible duplicate of [What is the most efficient way to deep clone an object in JavaScript?](http://stackoverflow.com/questions/122102/what-is-the-most-efficient-way-to-deep-clone-an-object-in-javascript) – Michał Perłakowski Sep 28 '16 at 13:56
  • I want a complete clone (i.e. deep I'd say). Maybe a workaround is to check if I really need such deepness? – GWorking Sep 28 '16 at 13:56
  • 1
    @Gothdo this is not a duplicate, the best way to do a deep clone is JSON http://stackoverflow.com/a/4591639/826815, the question here is whether I can workaround the limitation of a too large object by something but still through JSON, or if I have to switch – GWorking Sep 28 '16 at 13:59
  • 1
    I think you really shouldn't clone that object. It could take even seconds to complete. Why do you wish to clone it in the first place? Maybe some immutable datastructure could help you. – Tamas Hegedus Sep 28 '16 at 14:00
  • @Gerard See other answers on that question. – Michał Perłakowski Sep 28 '16 at 14:00
  • A javascript code having an object that results in a too long string is an atrocity in itself. See [this question](http://stackoverflow.com/questions/24153996/is-there-a-limit-on-the-size-of-a-string-in-json-with-node-js), you are likely storing over a gigabyte in that string, what on earth are you doing... Apart from that, JSON is probably just short code wise but not optimal when talking about cpu/memory usage. – ASDFGerte Sep 28 '16 at 14:08
  • @ASDFGerte I am no way reaching that 1.9 Gb of your post, this is an object derived from 8 JSON files of 40Mb each. I've found the error because the user decides how many files he wants to process, when I've processed 8 files then I've got the error – GWorking Sep 28 '16 at 14:12
  • @ASDFGerte also from the questions posted in the previous comments, JSON seems to be the fastest way to deep clone an object, you don't agree however? – GWorking Sep 28 '16 at 14:13
  • @Gerard If you're interested in performance when cloning objects see [this](http://stackoverflow.com/questions/122102/what-is-the-most-efficient-way-to-deep-clone-an-object-in-javascript/4591639#answer-5344074) post... – War10ck Sep 28 '16 at 14:14
  • @War10ck this claims JSON is fast, but that you can be faster if you (I simplify) have an object with a non-complex structure, which is not my case – GWorking Sep 28 '16 at 14:17
  • Actually, based on the question posted by @ASDFGerte I do see I don't have a too large object, but a too nested object (which I cannot simplify) – GWorking Sep 28 '16 at 14:18
  • Several things in the linked topics appear to be just wrong, e.g. `knownProp: obj.knownProp,` does not copy anything. I don't trust anyone's performance tests who writes things like that. I would need to inform myself to make a clear answer about how fast JSON is, but apart from it likely being implemented natively (which is a large boost), there are no reasons it should be faster than other implementations. – ASDFGerte Sep 28 '16 at 14:23
  • @ASDFGerte Did you read the post from top to bottom? The part you're referencing is where the authors mentioned that a manual copy/clone: _"JavaScript trace engines suck at optimizing for..in loops and checking hasOwnProperty will slow you down as well. Manual clone when speed is an absolute must."_ would be faster since you'd be avoiding `for(var .. in... )` and the lack of optimization around such loop. The line you pasted above ***is*** actually a copy from the old object `obj` to the new object `clonedObject`. I would trust this answer since it has 7 authors and 1048 upvotes... – War10ck Sep 28 '16 at 14:34
  • @War10ck Sorry, i don't understand, you need to elaborate further. Unless the data consists of one of the very few value types in javascript, assigning a variable to another is just a reference copy. – ASDFGerte Sep 28 '16 at 14:41
  • 1
    @ASDFGerte That's correct. The authors of that post were merely making a point as to how you would manually copy data. It would be up to the programmer to ensure that all data that is copied is by value as oppose to reference. This means expanding nested objects, possible recursively, and copying the individual properties rather than just referencing the object. You'd have to manually code it to work like the last example. For all intents and purposes, unless the object is a simple object I would stay far away from that last example. It would be much too difficult. – War10ck Sep 28 '16 at 14:52
  • @War10ck Thanks, i understand the idea now. That however means you don't only need to know the properties of the object you are cloning, but all properties' values' structures up to the point where all properties' values are primitives. That will almost never work, except the object is trivial. To me, the _recursive until all properties are primitives_ was not stressed enough in that post, especially with some of the `for ... in` it contains. – ASDFGerte Sep 28 '16 at 15:10

0 Answers0