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

    I've not read through the entire code (it's quite complex to handle all the scenarios that delete needs to handle, including partial selection), but I'd be rather surprised if it was this simplistic as that would be obviously slow with a large number of shapes.

    It's also not going to be hardware related (you seem to have removed that from your post) - since I was seeing 20 seconds for more objects than Steve, and he was talking about 10s of minutes. That's way too big a difference.

    So guessing isn't going to get anywhere - I'd sooner we try to ensure customer support can reproduce the problem then we can properly investigate why it is so slow for Steve. I'm guessing that there is something particular about his data which means that it is more complex than my deletion. For example, if you have large multi-part paths - this is one selected object in the layout editor, but many shapes that have to be actually deleted - and all the ROD info cleaned up too. Even then, it's surprising that dbDeleteObject in a loop is quicker. So we need to see the data to understand what is special and if there really is a problem in the software (which there may be, of course).

    Regards,

    Andrew.

Reply
  • Andrew Beckett

    I've not read through the entire code (it's quite complex to handle all the scenarios that delete needs to handle, including partial selection), but I'd be rather surprised if it was this simplistic as that would be obviously slow with a large number of shapes.

    It's also not going to be hardware related (you seem to have removed that from your post) - since I was seeing 20 seconds for more objects than Steve, and he was talking about 10s of minutes. That's way too big a difference.

    So guessing isn't going to get anywhere - I'd sooner we try to ensure customer support can reproduce the problem then we can properly investigate why it is so slow for Steve. I'm guessing that there is something particular about his data which means that it is more complex than my deletion. For example, if you have large multi-part paths - this is one selected object in the layout editor, but many shapes that have to be actually deleted - and all the ROD info cleaned up too. Even then, it's surprising that dbDeleteObject in a loop is quicker. So we need to see the data to understand what is special and if there really is a problem in the software (which there may be, of course).

    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.