mem-pool | Dynamic memory pool implementation

This may seem like a strange question but I'm trying to understand what exactly my code is doing memory wise in order to make it as efficient as possible.

When a database request is made such as req = objectStore.getAll( keyRange ); and the IDBRequest object is returned and the result provided later to the result property of the object, where is the object created? Is it just like any other JS object, allocated and released by the GC; and the variable req is just a reference to it, such that once the reference is broken the GC 'knows' the object is unreachable and releases the memory?

If many such requests are made over a short interval of time, is there a way to not consume additional RAM for each result?

For example, the process I'm interested in is a button click invokes two promises(one write and one read) through a Promise.allSettled, one that writes the current state to the database, and another that retrieves new data and builds a document fragment from it. If both fulfill, the fragment replaces a node in the DOM.

If a user rapidly clicks through this data, every read/getAll returns an IDBRequest with a result that is an array of objects, and that appears to consume more and more RAM until the GC runs. I can observe that the memory is eventually released, but was wondering if there is a way to not have that happen. Since I know what those objects are in terms of maximum size, could I write the IDBRequest to an exsiting object that is like a template object and only ever need one or two of them, such as one for current and one for the new request, rather than continually adding new objects until the GC releases those deemed unreachable?

Thank you for considering my question.

Thanks for the answer concerning where the IDBRequest object is allocated and advice concerning avoidance of memory leaks. Just to add further explanantion of what I was observing and wondering if it were possible, I'm adding this note.

There isn't a single global variable declared in my code, all exist within functions or are properties of a function object; and I set tem to null at the close of every function just in case I missed some scope/closure hidden reference. After finally getting a large portion of I/O within indexedDB working, I started to consider what would happen as a user worked within my application for an hour or two. Would memory use continually increase in the long term, even though I observed no issues during all the building and testing?

I filled the database with 500 data packets, meaning it takes more than one DB object to build a new DOM node; it is anywhere from 15 to 60 objects per node, depending upon what the user builds. So, I made every one of the 500 packets to be comprised of 60 objects and made those objects overly large in size for the testing, far greater than expected during appropriate use of the tool.

Then through a setInterval, the save-state, get-and-build promises were invoked every 500ms from packet 1 to 500; and I observed the data usage at the maro level only. The result appears to be that at any one time, there can be about one hundred of these packets in RAM between the GC runs. As the packets are retrieved, and nodes built and replaced, the RAM usage steadily increases and drops about five times during the traversal from packet 1 to 500. The max level of each increase prior to the drop is a little higher than the previous one. About 45 seconds or so after completion, the memory returns to just about where it was when the setInterval commenced.

Thus, fortunately, I don't think there is a memory leak. However, RAM usage is much as described in this article about using object pools. I'm interested in the graphs under the heading "Reduce Memory Churn, Reduce Garbage Collection taxes"--that saw-tooth pattern that consumes far more memory than is ever needed at any one time, when it could be like the second graph that is smaller, level, and requires fewer GC runs in total.

And the first answer to this SO question, at almost the very end, writes that this causes the GC to have to trace more objects also.

I'm not sure if the GC will run at a lower total RAM consumption or will wait until some maximum level is reached. Of course, I can test that on my machine, but that isn't very definitive overall.

I'm not building a game and a pause for a GC run isn't an issue; and a user should never click through 500 data packets in 250 seconds total and there will never be 500 packets of such a ridiculous size. Perhaps, that test was unrealistic; but the objective was to attempt to exacerbate the effect of using the tool for an extended period of time and generating many, many small objects throughout. Even a get/put for a minor edit creates a new object each time. These are concepts that I hadn't considered before and was just focused on how to get the I/O working accurately first.

When you consider how many objects sit around in RAM for a little while at least, waiting to be garbage collected, it seems reaonsable to simply hold the current packet at all times, such that a get operation is not required for an edit. Just edit the object in RAM and use a put operation only. Then all those get request result objects for edits are never created. But that doesn't eliminate the need for objects to hold the newly requested full data packets.

I understand that the browser's GC process is supposed to make all of this easier but it seems that, by doing so, it takes a lot out of the coders' control; and the advice that I see on SO in other questions is usually to not worry about it unless you experience an issue. I'm just an amateur at best but I'd prefer to understand what is happening in the background and code from the start with that in mind; and perhaps there is some stubbornness on my part that, regardless of how powerful the processor and size of RAM, my little tool ought to use as little resources as necessary or I haven't done my job.

I don't know if an object pool is a good technique anyway, but, even if it were, it appears that it would be an impossibility when it comes to retrieving data from indexedDB because the IDBRequest object is always created anew and could never be written to an existing object.

Thanks again for the explanation.