Delete large number of shapes efficiently

Sometimes this is a garbage collection issue. You can try the following:

    needNCells('list        5000000) ; *12 bytes = 60mb
    needNCells('dbobject    2000000) ; *12 bytes = 24mb

This will pre-allocate some memory for list objects and dbobjects and might reduce the number of garbage collection calls taking place when deleting a large number of objects. To see what types of objects might be getting garbage collected, and to see how much memory is set aside for different types of objects, try typing "gcsummary" into your CIW.

Derek

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.

 Andrew,

I'm running IC6.1.5-64b.500.15

I'd be just fine with 20 seconds but it's taking 10's of minutes... 

Three things I would try in this situation:

1. Use Layout-L mode rather than Layout-XL or Layout-GXL.  

The connectivity extractor may be wasting your time.

2. CIW -> Options ->  User Preferences -> Undo Limit = 0  

The undo list may be wasting your time.

3.  Don't select anything.  Use dbDeleteObject() rather than leHiDelete().

This avoids wasting time updating the selected set (and the "previous selected set").

If none of those help, you could try using the profiler to find out where the time is being spent.

 tweeks,

Your third suggestion seems to be the magic bullet. (I don't have a license for SKILL dev tools so can't access the profiler unfortunately)

I updated my script to this now:

 ;; delete alias, speeds up deleting thousands of shapes
procedure( myDelete()
    objects = geGetSelSet()
    cond(
    (objects == nil leHiDelete())
    (t
        geDeselectAllFig()
        foreach(obj objects
            dbDeleteObject(obj)
        );foreach
    )
    );cond
)

I had tried almost the same thing before, but I didn't have the geDeselectAllFig() in there. Adding that line makes all the difference.

 Thanks!

Thanks for the update, Steve.

It seems the moral of this story is that updating the selected set is a relatively expensive operation in Virtuoso.

Although something fishy appears to be happening here, because I don't see this performance issue. Maybe it happens in certain circumstances, and it would be worth exploring that via customer support in case there's something that needs optimizing. 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 would expect there to be some benefit in directly deleting the objects (i.e. what leHiDelete() is doing) because there would be no need to create (and destroy) the SKILL objects for each object being deleted. We could be doing something similar in our code (or should be) if it made that much of a difference in general.

So please talk to customer support about this.

Regards,

Andrew.

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())

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.