Sorting local block in JSON takes long time when expand selection is enabled

[Noitidart]

I have a large json document, when I hit sort, I want it to just expand in the local json block and sort that. This takes a long time though. Is this expected? If I disable "blocksort.expandSelection": false it then sorts fast, but then I can't use it for JSX and js objects and etc.

[1nVitr0]

@Noitidart This extension always had some issues with speed, due to it not actually using language specific AST representations, but rather a somewhat unwieldy amalgamation of regex checks. I have had a major refactoring on my list for a long time, though I'm not sure I can squeeze that into my schedule.

Do you have an example file? I might be able to some optimizations in the meantime.

[Noitidart]

Thank you very much for your response and amazing sort extension!

Whenever you can get to it that would be way appreciated. I will upload a json file and highlight section I ran it on in about 5 hours please.

[Noitidart]

Hey there, so I highlighted this part of a json file and then hit sort, and even with "blocksort.expandSelection" set to false it still takes a bit of time.

The full file is a 993 line json file of repeating blocks like this:

  "generic": {
    "continue": "Continue",
    "changesWillBeLostIfYouLeave": "You have changes that have not yet been submitted. They will be lost if you leave this screen. Are you sure you want to continue?",
    "lastUpdatedAgo": "Last updated {{timeAgo}}",
    "labeledValue": "<label>{{label}}: </label><value>{{value}}</value>",
    "moneyWithCurrency": "{{amount}} {{currency}}",
    "moneyWithoutCurrency": "{{amount}}",
    "getDirections": "Get Directions",
    "tapToZoom": "Tap to zoom",
    "canceled": "Canceled",
    "cancel": "Cancel",
    "okay": "Okay",
    "tryAgain": "Try Again",
    "tapToShare": "Tap to share",
    "share": "Share",
    "tapToGetDirections": "Tap to get directions",
    "yes": "Yes",
    "no": "No",
    "learn": "Learn",
    "serverError": "Server Error",
    "error": "Error",
    "unexpectedError": "Unexpected Error",
    "miles": "{{value}} mi",
    "kilometers": "{{value}} km",
    "loading": "Loading...",
    "close": "Close",
    "notProvided": "Not Provided",
    "retry": "Retry",
    "pleaseWait": "Please Wait",
    "tapForDetails": "Tap for details",
    "hideDetails": "Hide Details",
    "when": "When",
    "where": "Where",
    "description": "Description",
    "labeledMessage": "<bold>{{label}}</bold> {{message}}",
    "colonedLabel": "{{label}}: ",
    "back": "Back",
    "notNow": "Not now",
    "yesCancelNow": "Yes, cancel now",
    "resetAndContinue": "Reset Data & Continue",
    "reload": "Reload",
    "submit": "Submit",
    "undo": "Undo",
    "edit": "Edit",
    "message": "Message",
    "delete": "Delete",
    "copy": "Copy",
    "optional": "Optional",
    "address": "Address",
    "notes": "Notes"
  },

[1nVitr0]

1000 lines is not that much, it should definitely be in the sub 100ms range. My best guess is it hangs itself up on the xml properties inside the JSON. Ill give it a few tests and look into generally improving the performance. Might take me a while though, I'm usually only able to work this during the weekends.

[Noitidart]

No problem at all. It would be so awesome to have, but no pressure at all! Thank you! Best sorter out there. I use this in conjunction with smart sort, which sorts items on a row, like function parameters and array items, or anything in a line. Anything multiline, I use block sorter.

[globalhuman]

I've experienced the same performance issue when using this extension with markdown lists. I notice that if a list contains long lines > 120 characters long then the time can stretch on for seconds or not complete at all (Apple Macbook Pro M1 Pro). As soon as I reduce the maximum line length it works well.

This works quickly

- [x] checked item 0
- [x] checked item 1
- [x] checked item 2
- [x] checked item 3
- [x] checked item 4
- [x] checked item 5
- [x] checked item 6
- [ ] unchecked item 0
- [ ] unchecked item 1
- [ ] unchecked item 2
- [ ] unchecked item 3
- [ ] unchecked item 4
- [ ] unchecked item 5
- [ ] unchecked item 6
- [ ] item with link [abc](www.google.com)
- [ ] item with loing link [abc](www.google.com/this/can/go/on/for-a-while/lets/)

this doesn't complete in a reasonable amount of time

- [x] checked item 0
- [x] checked item 1
- [x] checked item 2
- [x] checked item 3
- [x] checked item 4
- [x] checked item 5
- [x] checked item 6
- [ ] unchecked item 0
- [ ] unchecked item 1
- [ ] unchecked item 2
- [ ] unchecked item 3
- [ ] unchecked item 4
- [ ] unchecked item 5
- [ ] unchecked item 6
- [ ] item with link [abc](www.google.com)
- [ ] item with loing link [abc](www.google.com/this/can/go/on/for-a-while/lets/seehowlongitcango/words/words/words/words/words/cat/dog)

[1nVitr0]

I was able to identify the issue and have considerably reduced the length of some core regular expressions. I am in the process of fixing the last test cases. Can only be a matter of years and I'll release the changes. Should reduce the time to extend the selections by a factor of at least 100, for some edge cases from minutes to milliseconds.

[Noitidart]

Thank you very much! That's really amazing!