'delete-line' lags

[hs2]

@SlickTeam:
v13.0.1 delete-line is much slower in comparison with v12.0.3 when editing large files (e.g. builtins.e).
Even if it's not asking for unsurrounding some code.
Is there something you can do to speed up this command again or are these lags just the price for some sophisticated functional enhancements ?
In this case I'd need to add a quick-delete-line command to directly call '_delete_line' and waste an add. shortcut
Thanks,
HS2

[Dennis]

You could write a delete_line() command clone that did not call maybe_unsurround_block() before calling _delete_line().  And since you are talking about delete-line rather than cut-line, you don't have to think about chaining clipboards, so this would be pretty staightforward.

However, if you are already committed to remembering a separate binding, you might want to consider leaving delete-line() alone, turning off def_auto_unsurround_block, and binding delete_code_block() to a key and just use that instead of delete_line() when you need the more sophisticated functionality.

This way delete-line will be fast, and you will still have the block oriented functions available when you need them.

[hs2]

@Dennis: Yes, this could be a way to go. Thanks for the hints !
But I'm still wondering why v13 delete-line is so much slower than v12.0.3 ? Is this by (new) design ?
HS2

[Dennis]

You are saying that for the exact same file, exact same line, v12.0.3 is faster? 

Do you have def_auto_unsurround_block turned off in 12.0.3? 

Why not profile it in v13 and maybe you'll be able to see where the bottleneck is.  If it is a very large file and the bottleneck is in vs[lang]_list_tags (statement tagging), then that would be expected behavior.

[hs2]

Yes, it's the same file and position (tried builtins.e and 1 large C++ file) and auto unsurround is ON b/c I like it.
I'm only using a patch on v12.0.3 to support straight deletion of the line on re-invocation of the command when the dialog is displayed. Simple but useful for me. I think I've read that this is also supported in v13, but I'll see.
So you're saying that v13 vs[lang]_list_tags (statement tagging) does more enhanced processing and takes a bit more time now, right ?
However, I'll re-do the testcases including profiling later on just to be sure. OTOH this could also be verified easily on your side. Maybe I did a mistake...
Thanks, HS2

[Dennis]

No, the list-tags shouldn't take any longer than it did in 12.0.3.  It's just that is where the profiling should show the majority of time spent.

I could verify on this end if I had your file and what line # to test on.

[hs2]

Strange again Dennis .. I can't really say why but now I get the same delete-line speed with both versions
I swear that I've repeated the same tests as yesterday ... I'm sorry - never mind.
(And I've noticed the slick window icon decorating the dialogs now.)
HS2

[ScottW, VP of Dev]

Sheesh! Harumph! Assorted other cries of outrage! I'm tempted to take away a hero point.  Not that you would miss it with that huge pile you've got. 

Not to worry. SlickEdit is a complex system and, as such, sometimes behaves in inexplicable ways. Let us know if you notice this again so we can try to pin it down.

[hs2]

You should get a HP for your postings - great fun ! (heck - you get one)
But I afraid there is sth. wrong with my machine here
I had to replace some hardware parts last time after a major crash and need to re-install everything.
But it seems that it didn't fully recover from that and behaves a bit flaky since that time...
HS2

[hs2]

... and thanks that the forced line deletion of 'delete-line' using the invoking shortcut made into the offical version.
I've added that sometime last year to my v12. Now it's proven that it's a good idea and I can throw away one more patch from my migration list
HS2