|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
Чудесно. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2019, 23:10 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
Swa111kealon(Ruslan), Многозадачности может и нет, а вот событие из прерывания может прилететьвот никак не пугает, гораздо легче и понятнее осталось понять что же ТС хочет вообще ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 00:22 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
Хочет чтоб его научили работать с хеш-табличками. Вон... как он бедняга циклы крутит. Не от хорошей жизни. Мдя. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 01:12 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
Посмотрел кучу реализаций хэш таблиц. Ни одна не понравилась. Не т детерминизма. Каждый malloc должен иметь свой free. А тут я рискую остаться с кучей мусора и фрагментированной памятью. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 09:24 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7, зачем вам выделять память по ходу? у вас вроде буфер стабильный выделен и его хватает у меня складывается впечатления что я слепому рассказываю о цветах ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 10:41 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7Посмотрел кучу реализаций хэш таблиц. Ни одна не понравилась. Не т детерминизма. Каждый malloc должен иметь свой free. А тут я рискую остаться с кучей мусора и фрагментированной памятью. Женя, вместо того чтобы сразу бросаться в ковыряния имплементаций хэш таблиц, подумай какая идея стоит за ними. И используй эту идею для решения своей задачки. Тогда и маллоки не потребуются. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 10:48 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
kealon(Ruslan)jenya7, зачем вам выделять память по ходу? у вас вроде буфер стабильный выделен и его хватает у меня складывается впечатления что я слепому рассказываю о цветах так работает хэш таблица. динамически выделает память под новый элемент. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 11:09 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7Посмотрел кучу реализаций хэш таблиц. Ни одна не понравилась. Не т детерминизма. Каждый malloc должен иметь свой free. А тут я рискую остаться с кучей мусора и фрагментированной памятью. Давай определимся с целями. Какой тебе нужен детерминизм? В первом варианте исходного кода у тебя был линейный поиск в массиве. Никакого детерминизма вообще не было по времени отклика. И вообще - это была фейеричная фейерия. По malloc, есть хеш таблицы которые работают внутри одного массива. Я такие еще изучал на 1-м курсе универа. Но у них есть компромисс между памятью и количеством промахов поиска. Вобщем.. определись что тебе надо. Иначе у сообщества сложится впечатление что ты - капризная девица. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 11:11 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
OoCcjenya7Посмотрел кучу реализаций хэш таблиц. Ни одна не понравилась. Не т детерминизма. Каждый malloc должен иметь свой free. А тут я рискую остаться с кучей мусора и фрагментированной памятью. Женя, вместо того чтобы сразу бросаться в ковыряния имплементаций хэш таблиц, подумай какая идея стоит за ними. И используй эту идею для решения своей задачки. Тогда и маллоки не потребуются. идея хэш таблицы прекрасна - немедленно получить индекс в таблице по ключу. это даст быстрый доступ к элементу, без перебора в цикле. только индекс не уникален. и вот тут начинаются танцы с бубнами. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 11:12 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
maytonjenya7Посмотрел кучу реализаций хэш таблиц. Ни одна не понравилась. Не т детерминизма. Каждый malloc должен иметь свой free. А тут я рискую остаться с кучей мусора и фрагментированной памятью. Давай определимся с целями. Какой тебе нужен детерминизм? В первом варианте исходного кода у тебя был линейный поиск в массиве. Никакого детерминизма вообще не было по времени отклика. И вообще - это была фейеричная фейерия. По malloc, есть хеш таблицы которые работают внутри одного массива. Я такие еще изучал на 1-м курсе универа. Но у них есть компромисс между памятью и количеством промахов поиска. Вобщем.. определись что тебе надо. Иначе у сообщества сложится впечатление что ты - капризная девица. не нашел хэш таблицы без malloc. это как раз то что нужно. а почему должен быть промах? мы ведь идем прямо по индексу. (idx=hash(key)). то есть возникает ситуация когда несколько элементов дадут тот же индекс. и сколько выделить памяти в статическом варианте? я не могу предсказать сколько ключей совпадут. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 11:17 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7OoCcпропущено... Женя, вместо того чтобы сразу бросаться в ковыряния имплементаций хэш таблиц, подумай какая идея стоит за ними. И используй эту идею для решения своей задачки. Тогда и маллоки не потребуются. идея хэш таблицы прекрасна - немедленно получить индекс в таблице по ключу. это даст быстрый доступ к элементу, без перебора в цикле. только индекс не уникален. и вот тут начинаются танцы с бубнами. ответ неверный. немедленно получается индекс бакета. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 11:25 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7и вот тут начинаются танцы с бубнами А какие танцы то? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 11:56 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
Допустим я получил table1.items - и все 12 элементов поместил в хэш таблицу //insert (key, value) insert(table1.items[0].reference_number, table1.items[0].priority_level); //malloc ................................................................................................. insert( table1.items[11].reference_number, table1.items[11].priority_level); //malloc приходят элементы //value = get(key) table2[idx].priority_level = get(table2[idx].reference_number); delete(table2[idx].reference_number) //free но элемент может быть удален из table2 за ненадобностью. и он никогда не обратиться к хэш таблице и не освободит память выделенную под него. Весь алгоритм такой. 1. Пришел список table1.items 2. По принятию списка иду в массиве table2 - ищу reference_number в списке table1.items и если нашел обновляю priority_level. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 11:57 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7kealon(Ruslan)jenya7, зачем вам выделять память по ходу? у вас вроде буфер стабильный выделен и его хватает у меня складывается впечатления что я слепому рассказываю о цветах так работает хэш таблица. динамически выделает память под новый элемент. так работают различные реализации устранения коллизий, кто сказал что это должно быть непременно так? Код: pascal 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 12:07 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7, jenya7не нашел хэш таблицы без malloc. для комплекта, удаление оттуда же Код: pascal 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 12:14 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7но элемент может быть удален из table2 за ненадобностью А может быть лучше мы узнаем ТЗ в его первоначальном варианте? Это же обычная практика - нагородить всякой херни, а потом с ней мучиться. Может быть там и нафиг не нужны никакие две таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 12:17 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
Лысый дядька, да мы у него уже вторую страницу это спрашиваем, не понимает :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 12:25 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7, У тебя по коду выделено 512штук * 4байта * 2штуки = 4096 байт и еще 12 * 4 * 2 = 48 байт статично. сколько тебе доступно памяти для решения этой задачи? Мы должны ориентироваться в цифрах. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 12:29 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
maytonjenya7, У тебя по коду выделено 512штук * 4байта * 2штуки = 4096 байт и еще 12 * 4 * 2 = 48 байт статично. сколько тебе доступно памяти для решения этой задачи? Мы должны ориентироваться в цифрах. не понял вопроса? проблема в скорости поиска элемента. table1 и table2 это статическая память в РАМ. я получил данные table1.items[0].reference_number = 100 table1.items[0].priority_level = 0 ------------------------------------------ table1.items[11].reference_number = 111 table1.items[11].priority_level = 11 в этот момент я перебираю все элемены в table2 и ищу совпадение table2[i].reference_number == table1.items[j].reference_number нашел? table2[i].priority_level == table1.items[j].priority_level вся проблема в быстроте поиска. это единственная проблема. в случае с хэш таблицей нужно учитывать что элементы в table2 могут быть удалены и выделенная память в хэш таблице не освободиться. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 12:48 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7, а 100% критично, что нужны самые-самые новые в момент отправки? Я сталкивался с системами датчиков, так там порешили проводить опрос датчиков насильно как можно чаще (~1/20 с). Но идея на клиенте была простая - содержать собственный буфер. Состояний общее число было сравнимое кол-во, неск. десятков, датчиков - вусмерть (напр. десятки тыс.) Правда первичная обработка была централизованной, но на случай поломки центра, были децентрализованные подбазы и слали напрямую. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 13:03 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
exp98jenya7, а 100% критично, что нужны самые-самые новые в момент отправки? Я сталкивался с системами датчиков, так там порешили проводить опрос датчиков насильно как можно чаще (~1/20 с). Но идея на клиенте была простая - содержать собственный буфер. Состояний общее число было сравнимое кол-во, неск. десятков, датчиков - вусмерть (напр. десятки тыс.) Правда первичная обработка была централизованной, но на случай поломки центра, были децентрализованные подбазы и слали напрямую. если бы не было критично не возник бы вопрос. как по мне не 100% но это не я решаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 13:05 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7...после получения списка содержащего 12 элементов (table1.items) я его сразу должен положить в таблицу. А в другом месте вытащить значение ... Насколько сразу ? Может никому не говорить, что была задержка? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 13:12 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7, есть простоеобъяснение для хотелок: Между получением и отправакой неминоемо проходит некоторое время. За этот промежуток отправака может успеть устареть. Конкретика требует цифр (для и от хотящих), т.е. некоторые показатели производительности. Обоснованные! ИМХО ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 13:19 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
Ну да, тоже важно всё или не всё пришедшее отправлять. Если не, т.е. очередь, стек, каждый 7-й ... т.е. по какому принципу. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 13:28 |
|
Быстрый поиск поля в массиве в С
|
|||
---|---|---|---|
#18+
jenya7не понял вопроса? проблема в скорости поиска элемента. table1 и table2 это статическая память в РАМ. я получил данные table1.items[0].reference_number = 100 table1.items[0].priority_level = 0 ------------------------------------------ table1.items[11].reference_number = 111 table1.items[11].priority_level = 11 в этот момент я перебираю все элемены в table2 и ищу совпадение table2[i].reference_number == table1.items[j].reference_number нашел? table2[i].priority_level == table1.items[j].priority_level вся проблема в быстроте поиска. это единственная проблема. в случае с хэш таблицей нужно учитывать что элементы в table2 могут быть удалены и выделенная память в хэш таблице не освободиться. Блинн. Почему с тобой так сложно? Почему ты решил что это есть проблема? Я не просто так спросил про доступную память. Потому что СУЩЕСТВУЮТ хеш таблички которые работают не ре-аллоцируя память. Но для этого им нужно дать чуть больше памяти (1.5-2 раза) чем твои элементы. ПОЭТОМУ я нудным голосом спрашиваю тебя еще раз - Сколько памяти можно выделить в твоём микро-контроллере или ХЗ в чем-то еще! Женя. Дорогой. Отвечай на вопросы экспертов. Если ты не отвечаешь - то можно сделать вывод что помощь тебе не нужна. И ты просто пришел сюда от скуки. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2019, 15:01 |
|
|
start [/forum/topic.php?fid=57&msg=39770123&tid=2017670]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
others: | 16ms |
total: | 165ms |
0 / 0 |