how to delete all the shapes on a specific layer

M

Marcel Preda

Guest
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:
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
Click to expand...
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.
 
Did you try to measure your function when executed with dbAccess?

--
Jean-Marc
 
On Sep 27, 6:23 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Marcel Preda wrote, on 09/27/10 10:35:

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

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.
Click to expand...
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-
purpose) then
info("--- %L %L %d \n" lx->layerName lx->purpose lx-
nShapes)
total = total + lx->nShapes
Click to expand...
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
 
Marcel Preda <marcel.preda@gmail.com> writes:

On Sep 28, 11:21 am, Jean-Marc Bourguet <j...@bourguet.org> wrote:
Did you try to measure your function when executed with dbAccess?

--
Jean-Marc

Hi Jean-Marc,

What is dbAccess ?
Any doc where I can read about it ?
Click to expand...
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
 
Jean-Marc Bourguet wrote, on 09/28/10 10:29:
Marcel Preda<marcel.preda@gmail.com> writes:

On Sep 28, 11:21 am, Jean-Marc Bourguet<j...@bourguet.org> wrote:
Did you try to measure your function when executed with dbAccess?

--
Jean-Marc

Hi Jean-Marc,

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

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,
Click to expand...
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.
 
On Sep 28, 11:21 am, Jean-Marc Bourguet <j...@bourguet.org> wrote:
Did you try to measure your function when executed with dbAccess?

--
Jean-Marc
Click to expand...
Hi Jean-Marc,

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


BR,
Marcel
 
On Sep 28, 1:11 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Jean-Marc Bourguet wrote, on 09/28/10 10:29:



Marcel Preda<marcel.pr...@gmail.com>  writes:

On Sep 28, 11:21 am, Jean-Marc Bourguet<j...@bourguet.org>  wrote:
Did you try to measure your function when executed with dbAccess?

--
Jean-Marc

Hi Jean-Marc,

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

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,

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.
Click to expand...
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:
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
Click to expand...
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.

--
Andrew Beckett
Senior Solution Architect - Cadence Design Systems Ltd (UK)
 
Marcel Preda wrote, on 09/29/10 13:37:
BR,
Marcel

Marcel,

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

Best Regards,

Andrew.

--
Andrew Beckett
Senior Solution Architect - Cadence Design Systems Ltd (UK)

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
Click to expand...
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.
 
BR,
Marcel

Marcel,

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

Best Regards,

Andrew.

--
Andrew Beckett
Senior Solution Architect - Cadence Design Systems Ltd (UK)
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top