Stats

  • Locked Locked
  • Replies 10
  • Subscribers 144
  • Views 17045
  • 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 said:

    If you are deleting the selected set, there is no good reason why it should be faster to do that in SKILL by deselecting first.

     

    I can imagine dbDeleteObject() doing a linear search through the internal list of selected objects so that its argument can be deseleted before deletion. (This assumes the selected set is represented as a list internally.) However, I agree there's no reason leHiDelete() would have to do that: It could just walk down the selection list deslecting and deleting everything that is deletable.

    If the programmers coded leHiDelete() to simply call dbDeleteObject() in a loop, that would explain how Steve gained a significant speed up by deselecting first!

    I would be curious to see how fast this is:

    geDeleteSelSet(hiGetCurrentWindow())
Reply

  • Andrew Beckett said:

    If you are deleting the selected set, there is no good reason why it should be faster to do that in SKILL by deselecting first.

     

    I can imagine dbDeleteObject() doing a linear search through the internal list of selected objects so that its argument can be deseleted before deletion. (This assumes the selected set is represented as a list internally.) However, I agree there's no reason leHiDelete() would have to do that: It could just walk down the selection list deslecting and deleting everything that is deletable.

    If the programmers coded leHiDelete() to simply call dbDeleteObject() in a loop, that would explain how Steve gained a significant speed up by deselecting first!

    I would be curious to see how fast this is:

    geDeleteSelSet(hiGetCurrentWindow())
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.