how to delete all the shapes on a specific layer

Hi there,

Is there a fast method to delete from a layout (it's a diva extracted
in fact) all the shapes on a specific layer ?

For now I'm using:
~~~~~~~~~~~~~~~~~~~~~~~
hiSetUndoLimit(0) ;; disable undo history - spped
foreach( lp cv~>lpps
if (lp~>layerName==myName && lp~>purpose==myPurpose then
foreach( shape lp~>shapes
dbDeleteObject(shape)
) ;; foreach

) ;; if
) ;; foreach
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
But I've noticed that the function is very slow, when the purpose is
"net" .
E.g. if I run the code for something like ("con" "drawing") , number
of shapes ~59K it tooks ~2 seconds
For ("via1" "net"), number of shapes ~712K it tooks ~26 minutes ~ 1560
seconds .

I think that in case of "net" purpose when the shape is deleted also
the associated net infop has to be updated.
Is it write ?
Is there any way to speedup the code ?


My icfb version 5.0.33.500.41

Thank you,
Marcel

 

Marcel Preda wrote, on 09/27/10 10:35:

Hi Marcel,

Not really. I have an enhancement request in with R&D to provide a function to
delete all the shapes on a layer-purpose-pair efficiently.

That said, it does sound rather slow - you might want to try profiling the code
with the SKILL profiler to see where it is taking all the time (maybe it's
garbage collection, or in the list creation - hard to be sure without profiling it).

That's also a rather old (and definitely unsupported) version - although I doubt
it would get magically faster in newer versions.

Wouldn't it be better to just not use saveInterconnect on the layer in the first
place in the Diva rules?

Regards,

Andrew.

 

Hi Andrew,

Diva rules are/were written by other team, I just want to extend the
verification with some ERC stuff.
And is not possible/allowed to modify the rule files (DP freeze,
etc).

I've run the skill code using profiling few times, everytime I was
restarting the icfb .
And I get:
Time spent in dbDeleteObject ~ 1100 secs
Time spent in gc ~ 200 secs

And my procedure (it deletes all the layers except few of them) is
bellow.
Some debug messages are still there.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*
Delete from cv all the layers' shapes, keep only shapes on l_lpps
layers .
*/
procedure( MyPckg_keepOnlyLayers(l_lpps cv)
let( (total)
total=0 ;; count number of deleted shapes
println(getCurrentTime())
hiSetUndoLimit(0)
foreach(lx cv->lpps
if( !exists(x l_lpps car(x) == lx->layerName && cadr(x) == lx-

info("--- %L %L %d \n" lx->layerName lx->purpose lx-

total = total + lx->nShapes
foreach(shape lx->shapes
dbDeleteObject(shape)
)
println(getCurrentTime())
) ;; if
) ;; foreach
info("%L %d\n" getCurrentTime() total)
t
) ;; let
) ;; proc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Could be done any improvement there ?

BR,
Marcel

 

Did you try to measure your function when executed with dbAccess?

 

Hi Jean-Marc,

What is dbAccess ?
Any doc where I can read about it ?


BR,
Marcel

 

tools/dfII/bin/dbAccess

It is probably documented somewhere under doc, but I didn't search
precisely where.

It is a skill interpreter which provides all the functions you need here.
What I'm trying to determine is if the slowness is intrinsic to what you
are doing or is due to some other maintenance that virtuoso is doing in
more advanced setup.

Yours,

 

Jean-Marc Bourguet wrote, on 09/28/10 10:29:

In addition to what Jean-Marc suggests trying, you can probably reduce the gc
overhead by using needNCells() to preallocate additional space (might need to do
this for list and dbobject types). Call gcsummary() before and after running
your code to see the number of list cells and dbobject types that have been created.

At least that should allow you to save 200 seconds.

Jean-Marc's suggestion will allow us to see if the overhead is due to any
virtuoso triggers kicking in. Especially if you have the layout open in an
editor window (and I can imagine it might be worse if it's Layout XL, because
there are more things that need to be kept up to date there).

Regards,

Andrew.

 

Hi there,

I've run dbAccess and I get the same total time.
After debuging with gcsummary() and using needNCells() I was able to
save ~ 3 minutes, as expected.

BR,
Marcel

 

Marcel Preda wrote, on 09/28/10 16:08:

Marcel,

Maybe you could log a service request with http://support.cadence.com and give
this example and ask for a duplicate CCR to be filed - the existing CCR number
is 728684.

Best Regards,

Andrew.

 

Hi Andrew,

Is it posible to view the description CCR #728684 on web page ?

If I go to "View Cadence Change Requests (CCRs)" I get a page with
message:
~~~~~~~~~~~~~~
There are no CCRs to view.
~~~~~~~~~~~~~

Doing a search by "728684" to "All Content" returns nothing.

BR,
Marcel

 

Marcel Preda wrote, on 09/29/10 13:37:

Hi Marcel,

It can only be viewed if the CCR was filed for you as a customer. This is
because potentially CCRs might have customer sensitive data in.

Even then, Cadence Online Support doesn't let you see the description.

But it's the same issue you're talking about here (I filed the CCR). In fact
looking at it, I'd also made the same suggestion about improving matters with
needNCells!

Rather oddly though, in the example in the CCR, it was only taking 100 seconds
to delete 5 million shapes. So yours is a LOT slower. My CCR was for IC613, so
maybe the performance is a lot better in OA for such an operation compared with
the very old (and unsupported) version you're using?

Regards,

Andrew.