extension flashing performance is 4x slower (VSC-242)

Describe the bug Flashing by extension task is almost 4 times slower than terminal command idf.py -p com flash.

To Reproduce Build project, set correct device port.

1. Click Flash button from toolbar at the bottom, watch esp-idf flash output.

Wrote 1057824 bytes (685281 compressed) at 0x00010000 in 60.8 seconds (effective 139.1 kbit/s)...
Hash of data verified.

1. Open termianl, run “idf.py.exe -p COMX flash”, watch terminal feedback.

Wrote 1058064 bytes (685377 compressed) at 0x00010000 in 16.0 seconds (effective 528.1 kbit/s)...
Hash of data verified.

Expected behavior Both should flash the device nice and quick.

Screenshots If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS Name & Version: [win10]
• VSCode Version: [0.13]
• ESP-IDF Version: [4.1]
• Python Version: [3.7]
• Hardware: ESP32-DevKitC with ESP32-WROOM-32

Additional context

full log from terminal (integrated windows power shell).

idf.py.exe -p COM7 flash  
Adding "flash"'s dependency "all" to list of commands with default set of options.
Executing action: all (aliases: build)
Running ninja in directory d:\workspace\vscode\workspace\hello\build
Executing "ninja all"...
[1/3] Performing build step for 'bootloader'
ninja: no work to do.
Executing action: flash
Running ninja in directory d:\workspace\vscode\workspace\hello\build
Executing "ninja flash"...
[1/4] Performing build step for 'bootloader'
ninja: no work to do.
[1/2] cmd.exe /C "cd /D D:\workspace\vscode\esp-idf.v4\components\esptool_py && D:\workspace\vscode\.../workspace/hello/build" -P D:/workspace/vscode/esp-idf.v4/components/esptool_py/run_esptool.cmake" 
esptool.py --chip esp32 -p COM7 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 4MB 0x8000 partition_table/partition-table.bin 0xd000 ota_data_initial.bin 0x1000 bootloader/bootloader.bin 0x10000 hello.bin
esptool.py v3.0-dev
Serial port COM7
Connecting....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 84:0d:8e:36:a7:c4
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Compressed 3072 bytes to 156...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (156 compressed) at 0x00008000 in 0.0 seconds (effective 1755.3 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 31...
Writing at 0x0000d000... (100 %)
Wrote 8192 bytes (31 compressed) at 0x0000d000 in 0.0 seconds (effective 5947.9 kbit/s)...
Hash of data verified.
Compressed 26944 bytes to 16643...
Writing at 0x00001000... (50 %)
Writing at 0x00005000... (100 %)
Wrote 26944 bytes (16643 compressed) at 0x00001000 in 0.4 seconds (effective 528.3 kbit/s)...
Hash of data verified.
Compressed 1058064 bytes to 685377...
Writing at 0x00010000... (2 %)
Writing at 0x00014000... (4 %)
Writing at 0x00018000... (7 %)
Writing at 0x0001c000... (9 %)
Writing at 0x00020000... (11 %)
Writing at 0x00024000... (14 %)
Writing at 0x00028000... (16 %)
Writing at 0x0002c000... (19 %)
Writing at 0x00030000... (21 %)
Writing at 0x00034000... (23 %)
Writing at 0x00038000... (26 %)
Writing at 0x0003c000... (28 %)
Writing at 0x00040000... (30 %)
Writing at 0x00044000... (33 %)
Writing at 0x00048000... (35 %)
Writing at 0x0004c000... (38 %)
Writing at 0x00050000... (40 %)
Writing at 0x00054000... (42 %)
Writing at 0x00058000... (45 %)
Writing at 0x0005c000... (47 %)
Writing at 0x00060000... (50 %)
Writing at 0x00064000... (52 %)
Writing at 0x00068000... (54 %)
Writing at 0x0006c000... (57 %)
Writing at 0x00070000... (59 %)
Writing at 0x00074000... (61 %)
Writing at 0x00078000... (64 %)
Writing at 0x0007c000... (66 %)
Writing at 0x00080000... (69 %)
Writing at 0x00084000... (71 %)
Writing at 0x00088000... (73 %)
Writing at 0x0008c000... (76 %)
Writing at 0x00090000... (78 %)
Writing at 0x00094000... (80 %)
Writing at 0x00098000... (83 %)
Writing at 0x0009c000... (85 %)
Writing at 0x000a0000... (88 %)
Writing at 0x000a4000... (90 %)
Writing at 0x000a8000... (92 %)
Writing at 0x000ac000... (95 %)
Writing at 0x000b0000... (97 %)
Writing at 0x000b4000... (100 %)
Wrote 1058064 bytes (685377 compressed) at 0x00010000 in 16.0 seconds (effective 528.1 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
Done

[igrr]

I think we can at least avoid using idf.baudRate for monitoring, for now. There is a Kconfig option CONFIG_ESPTOOLPY_MONITOR_BAUD that needs to be propagated as the monitor baud rate. If running idf.py monitor, this should happen automatically: https://github.com/espressif/esp-idf/blob/8bc19ba893e5544d571a753d82b44a84799b94b1/tools/idf_py_actions/serial_ext.py#L87-L88

[brianignacio5]

It will change ESP-IDF: Launch IDF Monitor for CoreDump / GDB-Stub Mode (will fix this asap) but ESP-IDF: Monitor your device command (the one the icon bar uses also CTRL/CMD + E M) monitor uses idf.py monitor which uses CONFIG_ESPTOOLPY_MONITOR_BAUD from the project’s sdkconfig.