Сообщение Re[4]: Задолбал Dick Seek со своей "невнимательностью" от 26.11.2025 7:57
Изменено 26.11.2025 7:57 Философ
Re[4]: Задолбал Dick Seek со своей "невнимательностью"
Здравствуйте, VladD2, Вы писали:
У меня времени немного, поэтому отвечаю пока на это небольшое подмножество реплик.
Ф>>Потому что HashSet более тяжеловесный — по крайней мере он опирается на хэш, который тут нафиг не упал, и добавление O(1) он не гарантирует. Потому что заранее известно, что ключи уникальны и как-либо гарантировать их уникальность не нужно.
VD>Чушь полная. HashSet и Dictionary очень даже лехковесный. Данные там хранятся в одном списке, а доступ идет за ~константное время. Для современных процессоров LinkedList вообще не лучший выбор, так как ухудшает локальность памяти (узлы шире и могут располагаться в разных участках памяти).
Влад, а подумать!?
Специально для тебя эксперимент провёл. Сам бы этого не делал — и так знал.
[cut = попробуй угадать, где кто (.net 4.8, AnyCPU, Release, w/o debug)]

[/cut]
Ф>>Это индекс очередного символа в source — само собой там символы из source итерируются.
VD>Вот именно! И там явно перебор еще один. А два вложенных цикла — это O(n²)
Это если ты итерируешься по одному и тому же. Пример: если сравнивать все символы со всеми символами текста, то будет квадрат, если сравнивать символы ключей с символами текста, то будет произведение кол-ва символов ключей на кол-во символов текста. Это очень разные множества.
Вот, прикинь, у тебя может быть 20 — 30 ключей (мой случай) и ещё много букав в тексте.
допустим ключей 20, по 4 символа
текст — 100М
Тогда:
O(n²) — 100М*100М
O(n*m) — 100М*20*4
У меня времени немного, поэтому отвечаю пока на это небольшое подмножество реплик.
Ф>>Потому что HashSet более тяжеловесный — по крайней мере он опирается на хэш, который тут нафиг не упал, и добавление O(1) он не гарантирует. Потому что заранее известно, что ключи уникальны и как-либо гарантировать их уникальность не нужно.
VD>Чушь полная. HashSet и Dictionary очень даже лехковесный. Данные там хранятся в одном списке, а доступ идет за ~константное время. Для современных процессоров LinkedList вообще не лучший выбор, так как ухудшает локальность памяти (узлы шире и могут располагаться в разных участках памяти).
Влад, а подумать!?
Специально для тебя эксперимент провёл. Сам бы этого не делал — и так знал.
| код | |
| |
[cut = попробуй угадать, где кто (.net 4.8, AnyCPU, Release, w/o debug)]

[/cut]
Ф>>Это индекс очередного символа в source — само собой там символы из source итерируются.
VD>Вот именно! И там явно перебор еще один. А два вложенных цикла — это O(n²)
Это если ты итерируешься по одному и тому же. Пример: если сравнивать все символы со всеми символами текста, то будет квадрат, если сравнивать символы ключей с символами текста, то будет произведение кол-ва символов ключей на кол-во символов текста. Это очень разные множества.
Вот, прикинь, у тебя может быть 20 — 30 ключей (мой случай) и ещё много букав в тексте.
допустим ключей 20, по 4 символа
текст — 100М
Тогда:
O(n²) — 100М*100М
O(n*m) — 100М*20*4
Re[4]: Задолбал Dick Seek со своей "невнимательностью"
Здравствуйте, VladD2, Вы писали:
У меня времени немного, поэтому отвечаю пока на это небольшое подмножество реплик.
Ф>>Потому что HashSet более тяжеловесный — по крайней мере он опирается на хэш, который тут нафиг не упал, и добавление O(1) он не гарантирует. Потому что заранее известно, что ключи уникальны и как-либо гарантировать их уникальность не нужно.
VD>Чушь полная. HashSet и Dictionary очень даже лехковесный. Данные там хранятся в одном списке, а доступ идет за ~константное время. Для современных процессоров LinkedList вообще не лучший выбор, так как ухудшает локальность памяти (узлы шире и могут располагаться в разных участках памяти).
Влад, а подумать!?
Специально для тебя эксперимент провёл. Сам бы этого не делал — и так знал.
Ф>>Это индекс очередного символа в source — само собой там символы из source итерируются.
VD>Вот именно! И там явно перебор еще один. А два вложенных цикла — это O(n²)
Это если ты итерируешься по одному и тому же. Пример: если сравнивать все символы со всеми символами текста, то будет квадрат, если сравнивать символы ключей с символами текста, то будет произведение кол-ва символов ключей на кол-во символов текста. Это очень разные множества.
Вот, прикинь, у тебя может быть 20 — 30 ключей (мой случай) и ещё много букав в тексте.
допустим ключей 20, по 4 символа
текст — 100М
Тогда:
O(n²) — 100М*100М
O(n*m) — 100М*20*4
У меня времени немного, поэтому отвечаю пока на это небольшое подмножество реплик.
Ф>>Потому что HashSet более тяжеловесный — по крайней мере он опирается на хэш, который тут нафиг не упал, и добавление O(1) он не гарантирует. Потому что заранее известно, что ключи уникальны и как-либо гарантировать их уникальность не нужно.
VD>Чушь полная. HashSet и Dictionary очень даже лехковесный. Данные там хранятся в одном списке, а доступ идет за ~константное время. Для современных процессоров LinkedList вообще не лучший выбор, так как ухудшает локальность памяти (узлы шире и могут располагаться в разных участках памяти).
Влад, а подумать!?
Специально для тебя эксперимент провёл. Сам бы этого не делал — и так знал.
| код | |
| |
| попробуй угадать, где кто (.net 4.8, AnyCPU, Release, w/o debug) | |
![]() | |
Ф>>Это индекс очередного символа в source — само собой там символы из source итерируются.
VD>Вот именно! И там явно перебор еще один. А два вложенных цикла — это O(n²)
Это если ты итерируешься по одному и тому же. Пример: если сравнивать все символы со всеми символами текста, то будет квадрат, если сравнивать символы ключей с символами текста, то будет произведение кол-ва символов ключей на кол-во символов текста. Это очень разные множества.
Вот, прикинь, у тебя может быть 20 — 30 ключей (мой случай) и ещё много букав в тексте.
допустим ключей 20, по 4 символа
текст — 100М
Тогда:
O(n²) — 100М*100М
O(n*m) — 100М*20*4