Stats

  • Locked Locked
  • Replies 10
  • Subscribers 144
  • Views 17428
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Delete large number of shapes efficiently

Steve Mikes

I have a large number of shapes that I need to remove from the layout. I find that the delete command seems to take exponenentially increasing amounts of time to run as the number of shapes selected goes up. This creates the perverse situation where it is significantly faster to repeatedly select smaller groups and hit delete than to select them all at once and hit delete. Here's an example:

(note: delete here is the leHiDelete() )

 Select 29,000 objects all at once and hit delete -> ~81 seconds

Manually select a few thousand at a time and delete until all 29,000 are gone  -> 22 seconds

 

That's a huge difference since the 22 seconds includes all the time it takes for me to drag the mouse around in between delete commands. This gets worse the more objects are selected. Is there a more efficient way to do this? I tried writing a recursive delete function that breaks up large lists into smaller ones before deleting, but it doesn't seem to yield any speed improvement:

;; delete alias, speeds up deleting thousands of shapes
procedure( myDelete(@optional objects)
    if(objects == nil
        objects = geGetSelSet()
    );if

    cond(
    (objects == nil leHiDelete())
    (length(objects) < 1000 leHiDelete())
    (t
        info("splitting list of length %d\n" length(objects))
        b = copy(nthcdr(length(objects)/2 objects))
        rplacd(nthcdr(length(objects)/2-1 objects) nil)
        a = copy(objects)
        myDelete(a)
        myDelete(b)
    )
    );cond
)
 

Parents
  • Andrew Beckett

    Although in this case, the code won't be doing anything particularly useful - it does a lot of list manipulation (which calls length multiple times, and copy multiple times, each of which will be creating a fair bit of garbage, as Derek said), but since it doesn't manipulate the selected set, the first leHiDelete() will delete the entire selected set, and the subsequent calls to leHiDelete will be doing nothing. 

    Given that the delete is implemented in C, I suspect that most attempts to make it faster by chunking the deletes into smaller pieces will be offset by the list manipulation that you're doing or by calling dbDeleteObject more often (if you used that instead).

    You didn't mention which version you're using - but either way, if you have a performance issue with the standard delete, you should contact customer support.

    I just deleted a million shapes in IC616 in 20 seconds (running on my Linux laptop) using the delete command (leHiDelete). That doesn't seem unreasonable for something you presumably wouldn't do very often...

    Regards,

    Andrew.

Reply
  • Andrew Beckett

    Although in this case, the code won't be doing anything particularly useful - it does a lot of list manipulation (which calls length multiple times, and copy multiple times, each of which will be creating a fair bit of garbage, as Derek said), but since it doesn't manipulate the selected set, the first leHiDelete() will delete the entire selected set, and the subsequent calls to leHiDelete will be doing nothing. 

    Given that the delete is implemented in C, I suspect that most attempts to make it faster by chunking the deletes into smaller pieces will be offset by the list manipulation that you're doing or by calling dbDeleteObject more often (if you used that instead).

    You didn't mention which version you're using - but either way, if you have a performance issue with the standard delete, you should contact customer support.

    I just deleted a million shapes in IC616 in 20 seconds (running on my Linux laptop) using the delete command (leHiDelete). That doesn't seem unreasonable for something you presumably wouldn't do very often...

    Regards,

    Andrew.

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.