Most efficient db function to move all shapes in a design?

I have found that working in no graph mode MAY be slower than working in graphics mode when dealing with millions of flat shapes, but need some more help to know of what I am trying to do is simply going to be time intensive - hours of computing time, if lucky enough not to exceed available memory….which has happened already in no graph mode.

Is there any advantage to using one set of functions dependent on graphics vs. no graphics for this type of data intensive processing?
My specific task is to select a set of flat shapes from a layout of flat shapes, make a new cell view with the selected set, and define its origin at a point within the selection bounding box area.

There are many ways to do this, but the challenge has been the number of shapes to deal with, and hence the efficiency aspect of the thread title.

Making an assumption that working in no graph mode would be more efficient than graphics mode, I have tried deleting shapes using dbGetOverlaps() and working with what is left, but this seems to have been the worst approach.

I have tried using leMakeCell() in no graph mode, passing it a list of shapes found by dbGetOverlaps(), and a new origin point, and though it has to do less processing, I killed it after watching the screen for 2 hours.

Finally, I am stuck trying to figure out how to work in graphics mode, scripting the use of the leHiMakeCell() form.
I'm trying to use the form because in graphics mode, getting a selection set of shapes seems to take much less time than non-graphically.
The form then takes the selection set to create the new cell.
essentially:
(create win, open cell view into win)
geSelectArea(<args>) ; selects shapes
leHiMakeCell() ; opens form
form=hiGetCurrentForm() ; does not consistently get the form…it has actually worked only once
form~>cellName~>value="new cell name"
hiFormDone(form)
dbClose(cell view)

Almost every time I try this, the "form" variable does not get the form ID of the leHiMakeCell() form.
I don't know if it is because the geSelectArea() function is not done when the form is called, or if there is some other way to put values into the form.

I have found that working in no graph mode MAY be slower than working in graphics mode when dealing with millions of flat shapes, but need some more help to know of what I am trying to do is simply going to be time intensive - hours of computing time, if lucky enough not to exceed available memory….which has happened already in no graph mode.

Is there any advantage to using one set of functions dependent on graphics vs. no graphics for this type of data intensive processing?
My specific task is to select a set of flat shapes from a layout of flat shapes, make a new cell view with the selected set, and define its origin at a point within the selection bounding box area.

There are many ways to do this, but the challenge has been the number of shapes to deal with, and hence the efficiency aspect of the thread title.

Making an assumption that working in no graph mode would be more efficient than graphics mode, I have tried deleting shapes using dbGetOverlaps() and working with what is left, but this seems to have been the worst approach.

I have tried using leMakeCell() in no graph mode, passing it a list of shapes found by dbGetOverlaps(), and a new origin point, and though it has to do less processing, I killed it after watching the screen for 2 hours.

Finally, I am stuck trying to figure out how to work in graphics mode, scripting the use of the leHiMakeCell() form.
I'm trying to use the form because in graphics mode, getting a selection set of shapes seems to take much less time than non-graphically.
The form then takes the selection set to create the new cell.
essentially:
(create win, open cell view into win)
geSelectArea(<args>) ; selects shapes
leHiMakeCell() ; opens form
form=hiGetCurrentForm() ; does not consistently get the form…it has actually worked only once
form~>cellName~>value="new cell name"
hiFormDone(form)
dbClose(cell view)

Almost every time I try this, the "form" variable does not get the form ID of the leHiMakeCell() form.
I don't know if it is because the geSelectArea() function is not done when the form is called, or if there is some other way to put values into the form.