Я могу разделить большой dll на 1 dll в классе?

Я не нашел никакого специального алгоритма в Networkx для этой цели. Вы можете использовать следующую функцию, которая использует алгоритм Беллмана-Форда:

import networkx as nx

G = nx.DiGraph()
G.add_weighted_edges_from([(1, 2, -50), (2, 3, 40), (3, 4, -50),
                           (4, 5, -90), (1, 6, -105)])

def func(graph, source, target, start_weight):
    total = start_weight
    path = []
    p = nx.bellman_ford_path(graph, source, target)
    for u, v in zip(p, p[1:]):
        total += G[u][v]['weight']
        path.append(u)
        if total < 0:
            return path
    else:
        return path

print(func(G, 1, 5, 100))
# [1, 2, 3, 4]

print(func(G, 1, 6, 100))
# [1]
6
задан Community 23 May 2017 в 11:45
поделиться

2 ответа

Просто ... Зачем? Наличие большого количества библиотек DLL может повлиять на производительность при запуске приложения (из-за «слияния»). Он также в значительной степени сразу же пострадает от циклических ссылок, что является плохой вещью .

Так как .NET-код (по умолчанию) получает JITted при первом использовании, нет огромное влияние на наличие дополнительных классов в dll, которые не используются в этом приложении. Они просто сидят тихо, никому не мешая.

Сама стоимость управления наличием dll на класс сделает развертывание и т.д. мучительным .

В общем, я не могу придумать разумную причину сделать это ...

что является плохой вещью .

Так как .NET-код (по умолчанию) получает JITted при первом использовании, нет огромного влияния на наличие дополнительных классов в dll, которые не получают используется в этом приложении. Они просто сидят тихо, никому не мешая.

Сама стоимость управления наличием dll на класс сделает развертывание и т.д. мучительным .

В общем, я не могу придумать разумную причину сделать это ...

что является плохой вещью .

Так как .NET-код (по умолчанию) получает JITted при первом использовании, нет огромного влияния на наличие дополнительных классов в dll, которые не получают используется в этом приложении. Они просто сидят тихо, никому не мешая.

Сама стоимость управления наличием dll на класс сделает развертывание и т.д. мучительным .

В общем, я не могу придумать разумную причину сделать это ...

8
ответ дан 8 December 2019 в 13:02
поделиться

Ответ, который вы получите здесь, ничем не отличается от ответа на другой вопрос: поместить в отдельный проект для каждой отдельной DLL .

Что я хочу спросить вас, каково ваше понимание определения «класса». Один класс на DLL, вероятно, означает, что вы не очень хорошо знаете, как работают сборки, пространства имен и классы.

Скажите нам, что вы действительно хотите сделать? Потому что то, что, по вашему мнению, вы должны делать для решения этой проблемы (например, создание одной библиотеки DLL на класс), нецелесообразно.

Обновление

Учитывая контекст вашего требования (например, веб-приложение Silverlight), я пришел к выводу, что Разделение ваших классов на несколько библиотек DLL не приведет к повышению производительности на веб-странице ASP.NET, поскольку:

  • DLL-библиотеки используются только сервером, они не загружаются через HTTP в ваш браузер.
  • Как только DLL загружается веб-приложением, она не загружается снова - независимо от того, как многие пользователи используют ваш сайт одновременно. Один экземпляр DLL на сервер.
  • При запуске веб-приложения оно будет загружать все библиотеки , от которых оно зависело, независимо от того, будете ли вы использовать его.

Итак, с вашими требованиями это Вероятно, лучше НЕ использовать Silverlight для вашего приложения, учитывая ограничение пропускной способности. Возможности, которые вы можете исследовать:

  • Изучение методов AJAX, в частности JSON (и, вероятно, не ASP.NET AJAX и его легко используемой UpdatePanel)
  • Изучение jQuery для поиска элементов управления, которые будут реализовывать в JavaScript то, что вы хотите сделать с помощью Silverlight
7
ответ дан 8 December 2019 в 13:02
поделиться
Другие вопросы по тегам:

Похожие вопросы: