Marcel Preda
Guest
Mon Sep 27, 2010 12:35 pm
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
Andrew Beckett
Guest
Mon Sep 27, 2010 4:23 pm
Marcel Preda wrote, on 09/27/10 10:35:
Quote:
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.
Jean-Marc Bourguet
Guest
Tue Sep 28, 2010 9:21 am
Did you try to measure your function when executed with dbAccess?
--
Jean-Marc
Marcel Preda
Guest
Tue Sep 28, 2010 10:20 am
On Sep 27, 6:23 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Quote:
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.
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-
Quote:
purpose) then
info("--- %L %L %d \n" lx->layerName lx->purpose lx-
nShapes)
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
Jean-Marc Bourguet
Guest
Tue Sep 28, 2010 10:29 am
Marcel Preda <marcel.preda_at_gmail.com> writes:
Quote:
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,
--
Jean-Marc
Andrew Beckett
Guest
Tue Sep 28, 2010 11:11 am
Jean-Marc Bourguet wrote, on 09/28/10 10:29:
Quote:
Marcel Preda<marcel.preda_at_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.
Marcel Preda
Guest
Tue Sep 28, 2010 11:35 am
On Sep 28, 11:21 am, Jean-Marc Bourguet <j...@bourguet.org> wrote:
Quote:
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 ?
BR,
Marcel
Marcel Preda
Guest
Tue Sep 28, 2010 6:08 pm
On Sep 28, 1:11 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Quote:
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.
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
Andrew Beckett
Guest
Wed Sep 29, 2010 9:55 am
Marcel Preda wrote, on 09/28/10 16:08:
Quote:
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,
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)
Andrew Beckett
Guest
Wed Sep 29, 2010 3:05 pm
Marcel Preda wrote, on 09/29/10 13:37:
Quote:
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
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.
Marcel Preda
Guest
Wed Sep 29, 2010 3:37 pm
Quote:
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
