Nano Hash - криптовалюты, майнинг, программирование

Какую структуру данных следует использовать для целочисленных пар?

Я пытаюсь оптимизировать свой код, чтобы ускорить вычисления и уменьшить потребление памяти. Мне нужно хранить данные за год и стоимость. В настоящее время я использую фиксированные массивы для хранения значений.

Например, у меня был бы целочисленный массив:

integer[0] = 0,  
integer[1] = 200,  
integer[2] = 0,  
integer[3] = 0,  
integer[4] = 200,  
integer[5] = 0,  
...   
integer[99] = 0

Где integer[0] = 0 означает, что в 2015 году стоимость составляет 0 долларов США, integer[1] = 200 означает, что в 2016 году стоимость составляет 200 долларов США и так далее. Поскольку у меня есть миллионы таких массивов, хранящихся в памяти и используемых для вычислений, я хочу свести к минимуму влияние памяти и производительности.

Чтобы уточнить, я использую данные для построения графиков. Как только я присваиваю затраты годам, я суммирую массивы на основе серий объектов, частью которых они являются. Затем я отображаю их в столбчатой ​​диаграмме с накоплением.

Есть ли лучший способ хранения моих данных? Я рассматриваю список ключей и значений, поэтому я храню только ненулевые затраты и год, но я не знаю, сильно ли это поможет.

list arrays c# key-value data-structures
29.07.2015

  • Лучший ответ будет сильно зависеть от того, как именно вы используете эти данные. Можете ли вы уточнить? 29.07.2015
  • @Diosjenin Я добавил немного информации. Надеюсь, это поможет? 29.07.2015
  • Оно делает. Единственная проблема, которую я вижу в ответе Джейкоба, заключается в том, что Словарь не будет внутренне сохранять элементы, отсортированные по годам, поэтому вам придется либо а) перебирать словарь и сортировать их самостоятельно (используя LINQ или пользовательскую функцию), либо б ) выполнить итерацию по известным годам и посмотреть, содержит ли словарь каждый год в качестве ключа. Если любой из них будет приемлемым компромиссом производительности, то словарь вам подойдет. Если нет, дайте нам знать. 29.07.2015

Ответы:


1

Используйте Dictionary<int, int>:

var costs = new Dictionary<int, int> {
    { 2014, 150 },
    { 2016, 200 },
};

Это может не обязательно использовать меньше памяти, но вы можете избежать хранения пустых записей, и значение данных немного более очевидно.

29.07.2015
  • Это пример списка я рассматриваю список "ключ-значение". Это также хороший ответ. 29.07.2015
  • Спасибо за решение. Как вы думаете, это приведет к значительному увеличению производительности по сравнению с тем, как я это делаю сейчас? 29.07.2015
  • Он не будет. В зависимости от размера ваших данных это может сэкономить потребление памяти, но массив будет намного быстрее. 29.07.2015
  • @AC Настоящее улучшение заключается в удобочитаемости. Что-то вроде costByYear[2016] имеет больше смысла, чем costByYear[1]. 29.07.2015
  • @Jacob, массив будет намного быстрее, почему ты так думаешь? Поиск по словарю - это O (1), что совпадает с массивом. Единственная разница заключается в вызове GetHashCode для поиска нужного сегмента и вызовах Equals для всех ключей в этом сегменте. 29.07.2015
  • @ Джейкоб, понятно. Моя главная цель заключалась в повышении производительности и уменьшении памяти. В противном случае, возможно, не стоит пытаться изменить весь мой проект только для удобства чтения. 29.07.2015
  • Также стоит отметить, что если эти массивы очень большие или если их очень много, улучшение производительности, полученное от небольшого словаря, вписывающегося в кеш, может перевесить падение из-за затрат времени на хеширование ключей. 29.07.2015
  • @DStanley, O (1) не всегда означает быстрее, это просто означает, что он будет хорошо масштабироваться. Это постоянное время не равно нулю. O(1) со словарем медленнее, чем O(1) с массивом. Это было моей главной мыслью. 29.07.2015
  • @Jacob Я понимаю это и согласен с тем, что массивы быстрее, чем словари, но гораздо быстрее кажется преувеличением. Я бы не хотел, чтобы ОП решил не использовать словари, основываясь на ложном предположении, что они намного медленнее. 29.07.2015
  • Это потребовало бы гораздо больше памяти, чем массив, и было бы значительно медленнее в производительности. В то время как подход со словарем имеет преимущество в удобочитаемости (т.е. costByYear[2016]), вы можете сделать индексирование массива вполне читаемым с помощью costByYear[2016-baseYear]. 29.07.2015
  • Да, если производительность является единственным соображением здесь, вы не можете стать лучше, чем массив. 29.07.2015
  • @A C - Поскольку ваши числа невелики, вы можете рассмотреть возможность использования short вместо int, чтобы уменьшить потребление памяти. Если вы хотите уменьшить его еще больше, вы можете сжать числа, но тогда производительность также может снизиться. 30.07.2015

    • 2

    Если (1) все, что вы делаете, это суммирование, и (2) не требуется доступ для поиска к любому заданному значению, а просто перебираете их, и (3) ваши значения действительно разрежены,

    тогда что-то вроде

    integer[0] = 200,  
integer[1] = 200,  
...

    в сочетании с

    year[0] = 2016,
year[1] = 2019,
...

    даст вам минимальный объем памяти без потери эффективности. Словари (хэши) стоят памяти; массив является наиболее экономичным с точки зрения использования памяти, и тем более, если у вас есть значение по умолчанию (0), которое можно принять за пропущенные годы. Но это работает только в том случае, если вам не нужно выполнять поиск, поскольку с этой структурой это упражнение O (n).

    31.07.2015
    Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..