Я должен быть обеспокоен скоростью словаря.NET?

Question

Я должен быть обеспокоен скоростью словаря.NET?

Указание типа как строки в порядке, но всегда немного меня решает, что мы в основном обходим парсер. Поэтому вам лучше не пропустить ни одну из этих литералов:

def __add__(self, other: 'Position') -> 'Position':
    return Position(self.x + other.x, self.y + other.y)

Небольшое отклонение заключается в использовании связанного типаvar, по крайней мере, тогда вы должны написать строку только один раз при объявлении typevar:

from typing import TypeVar

T = TypeVar('T', bound='Position')

class Position:

    def __init__(self, x: int, y: int):
        self.x = x
        self.y = y

    def __add__(self, other: T) -> T:
        return Position(self.x + other.x, self.y + other.y)

25

dictionary optimization arrays c#

задан John Saunders 14 December 2009 в 20:22

11 ответов

Вы можете захотеть взглянуть на класс KeyedCollection в System.ObjectModel. Из описания MSDN «предоставляет абстрактный базовый класс для коллекции, ключи которой встроены в значения».

-3

ответ дан Anton 15 October 2019 в 14:44

Здравствуйте, я буду создавать проект который будет использовать поиск по словарю и вставок совсем немного. Это что-то о чем беспокоиться?

Да. Всегда разумно заранее учитывать факторы производительности.

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

Кроме того, если я провожу сравнительный анализ и тому подобное и это действительно плохо, то что за лучший способ заменить словарь на что-нибудь еще?

Лучший способ сделать это - создать разумный уровень абстракции. Если у вас есть класс (или интерфейс), который представляет абстрактный тип данных «вставка» и «поиск», то вы можете заменить его внутренние компоненты, не меняя ни одного из вызывающих.

Обратите внимание, что добавление уровня абстракции само по себе имеет производительность Стоимость. Если ваше профилирование показывает, что уровень абстракции слишком дорог, если дополнительная пара наносекунд на вызов слишком велика, вам, возможно, придется избавиться от уровня абстракции. Опять же, это решение будет основано на реальных данных о производительности.

Можно ли использовать массив с "хешированием" ключи даже быстрее? Это не но поможет ли время вставки?

Ни вы, ни кто-либо другой, читающий это, возможно, не сможете узнать, какой из них быстрее, пока вы не напишете его в обе стороны, а затем не проведете тест в обоих направлениях в реальных условиях . Выполнение этого в «лабораторных» условиях исказит ваши результаты; вам нужно понять, как все работает, когда сборщик мусора испытывает реальную нехватку памяти и так далее. Вы также можете спросить нас, какая лошадь будет бежать быстрее в Кентукки Дерби в следующем году. Если бы мы знали ответ, просто взглянув на гоночную форму, мы все уже были бы богаты. Вы не можете ожидать, что кто-то узнает, какой из двух полностью гипотетических, неписаных фрагментов кода будет быстрее при неуказанных условиях!

66