Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
jenya7MBojenya7, какое ещё условие нужно? спасибо. сделал так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. похоже что работает. .................................... а я бы возвращал положительное число, индекс+1 если найдено, а если не найдено - отрицательный индекс вставки - и параметр found тогда не нужен. А чего изобретаете то? или так, язык поучить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 11:30 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
плохо сказал. можно задачу ф-ции переформулировать так - найти индекс первого элемента, который больше или равен ключу. Тогда вызывающая сторона сможет посмотреть - если ей вернули -1 - вставлять в конец, если ноль и больше - посмотреть что лежит на этом месте - ключ - значит нашлось, не ключ - тогда это место вставки. параметр found точно не нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 11:40 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
[quot Vladimir Baskakov]jenya7пропущено... .................................... а я бы возвращал положительное число, индекс+1 если найдено, а если не найдено - отрицательный индекс вставки - и параметр found тогда не нужен. А чего изобретаете то? или так, язык поучить? Задача такая. Есть массив пакетов приходящих по TCP, в принципе не важно откуда они приходят. Я должен хранить эти пакеты, для этого я создал массив пакетов. Глубина хранения пока 512 хотя может вырасти до пару тысяч, это еще TBD. То есть размер массива пока 512. В приходящем пакете есть ИД и команда - добавить пакет, удалить пакет, редактировать пакет. Доступ к пакету должен быть максимально быстрым. Находить ИД пакета простым перебором в for долго. Поэтому решил находить бинарным поиском и если ИД не найден вставлять его на его место, чтоб массив всегда был сортирован по ИД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 13:47 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
пока что сделал так. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 13:53 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
тестирую так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. пока вроде вставка и удаление проходят нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 13:57 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
Задача такая. Есть массив пакетов приходящих по TCP, в принципе не важно откуда они приходят. Я должен хранить эти пакеты, для этого я создал массив пакетов. Глубина хранения пока 512 хотя может вырасти до пару тысяч, это еще TBD. То есть размер массива пока 512. В приходящем пакете есть ИД и команда - добавить пакет, удалить пакет, редактировать пакет. Доступ к пакету должен быть максимально быстрым. Находить ИД пакета простым перебором в for долго. Поэтому решил находить бинарным поиском и если ИД не найден вставлять его на его место, чтоб массив всегда был сортирован по ИД. чисто теоретически, https://habrahabr.ru/post/65617/ https://ru.wikipedia.org/wiki/B-дерево есть разные упорядоченные структуры данных для хранения сортированных данных - всякие бинарные и сбалансированные деревья. может быть среди них поискать. или - хэш-таблицы. чтобы по целому вычислять ключик, где искать - в каком сегменте, и там уже перебором или бинарным поиском. Мне думается, что хэширование - поможет. допустим, если храним 2000 значений - захешировали на сотню, и вот уже в каждом массивчике перебираемых 20 единиц (в среднем) - и вставлять быстро и искать нормально. А перерасход памяти для такого количества значений - мизернейший. ============================ всего доброго. PS а почему си, а не с++ с огромным массивом оптимизированных уже библиотек? ну дело хозяйское, в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 14:43 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
Vladimir BaskakovЗадача такая. Есть массив пакетов приходящих по TCP, в принципе не важно откуда они приходят. Я должен хранить эти пакеты, для этого я создал массив пакетов. Глубина хранения пока 512 хотя может вырасти до пару тысяч, это еще TBD. То есть размер массива пока 512. В приходящем пакете есть ИД и команда - добавить пакет, удалить пакет, редактировать пакет. Доступ к пакету должен быть максимально быстрым. Находить ИД пакета простым перебором в for долго. Поэтому решил находить бинарным поиском и если ИД не найден вставлять его на его место, чтоб массив всегда был сортирован по ИД. чисто теоретически, https://habrahabr.ru/post/65617/ https://ru.wikipedia.org/wiki/B-дерево есть разные упорядоченные структуры данных для хранения сортированных данных - всякие бинарные и сбалансированные деревья. может быть среди них поискать. или - хэш-таблицы. чтобы по целому вычислять ключик, где искать - в каком сегменте, и там уже перебором или бинарным поиском. Мне думается, что хэширование - поможет. допустим, если храним 2000 значений - захешировали на сотню, и вот уже в каждом массивчике перебираемых 20 единиц (в среднем) - и вставлять быстро и искать нормально. А перерасход памяти для такого количества значений - мизернейший. ============================ всего доброго. PS а почему си, а не с++ с огромным массивом оптимизированных уже библиотек? ну дело хозяйское, в целом. я думал про хэш. но пока остановились на бинарном поиске. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 17:30 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
а почему? может быть на макете сверить производительность? от целого хэш-функция на 10 000 значений посчитается практически влет, и скорее всего в каждом из этих 10000 массивов будет сидеть ну три, ну пять ключей. если всего значений 2000. Хэширование даст заметно - лучшее масштабирование при увеличении кол-ва эл-тов, сокращая расходы на вставку - меньше памяти надо двигать. ну конечно по ситуации - если код для микроконтроллера - это одно, а если для машинки с кучей памяти под современной осью - совсем другое. но, не настаиваю. кому как удобнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 17:45 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
Vladimir Baskakovа почему? может быть на макете сверить производительность? от целого хэш-функция на 10 000 значений посчитается практически влет, и скорее всего в каждом из этих 10000 массивов будет сидеть ну три, ну пять ключей. если всего значений 2000. Хэширование даст заметно - лучшее масштабирование при увеличении кол-ва эл-тов, сокращая расходы на вставку - меньше памяти надо двигать. ну конечно по ситуации - если код для микроконтроллера - это одно, а если для машинки с кучей памяти под современной осью - совсем другое. но, не настаиваю. кому как удобнее. я представил две опции. но народ выбрал бинарный поиск. я не стал спорить. если будем терять пакеты попробуем хэш. есть еще красно-черное дерево которое, как говорят, на больших массивах дает хорошие результаты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 17:49 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
что еще по ходу подумалось (я уже давным-давно не сишник, по старой памяти) char * strchr( const char * string, int symbol); вроде бы эффективно задействует возможности процессора для поиска в области памяти. вроде бы scas http://programm.ws/page.php?id=129 может быть не сортировать, а искать на уровне байт? найти первый байт искомого числа. проверить совпадение следующих. мне кажется тут есть о чем подумать, если уж надо очень, очень быстро искать в сравнительно-небольших массивах, до 10-20 килобайт вплоть до того, что весь массив в котором ищем держать в строковом виде 16-ричных чисел и искать там строковыми, высокооптимизированными ф-циями, которые были и есть в составе стандартной б-ки Си. то есть, вариантов на попробовать, даже в самом простом случае, море. Попробуйте, шутки ради, вдруг да выйдет.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 18:11 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
jenya7я думал про хэш. но пока остановились на бинарном поиске. Тут выбор между быстро искать и и быстро вставлять/удалять. Бинарный поиск ищет достаточно быстро, не факт что хэштаблица будет искать быстрее при нескольких тысячах элементов. Но вставка/удаление требует сдвига существенной части массива, что не быстро. Если вставок/удалений относительно немного, то твой способ будет нормально работать. Надо просто затестить с нагрузкой похожей на реальную. Если производительность устроит, то можешь оставить как есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 18:13 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
jenya7я представил две опции. но народ выбрал бинарный поиск. я не стал спорить. если будем терять пакеты попробуем хэш. есть еще красно-черное дерево которое, как говорят, на больших массивах дает хорошие результаты. а время то меряли? профилировали? может и не пробежка по несортированному массиву его занимает? а какая-то предобработка, принятие пакетов, или постобработка? ну, я против народа то не пойду.... народ сказал, значит так надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 18:16 |
|
||
|
Бинарный поиск в С
|
|||
|---|---|---|---|
|
#18+
Dima Tjenya7я думал про хэш. но пока остановились на бинарном поиске. Тут выбор между быстро искать и и быстро вставлять/удалять. Бинарный поиск ищет достаточно быстро, не факт что хэштаблица будет искать быстрее при нескольких тысячах элементов. Но вставка/удаление требует сдвига существенной части массива, что не быстро. Если вставок/удалений относительно немного, то твой способ будет нормально работать. Надо просто затестить с нагрузкой похожей на реальную. Если производительность устроит, то можешь оставить как есть. вот и я к тому, что надо понять где затыки сейчас, и где они могут быть, а уж потом выбор выбирать. (шутка) надеюсь, это курсовичок, а не атомный ледокол с горячей заменой кода на проде. когда бесконечный цикл не даст опустить графитовый стерженек....( конец шутки) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2017, 18:21 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=39541245&tid=1340253]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
183ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 298ms |
| total: | 571ms |

| 0 / 0 |
