Кодирование к интерфейсу скорее затем реализация подразумевают хит производительности?
Пожалуйста, проверьте вашу регистрационную роль пользователя.
Чтобы прочитать подробности конфигурации набора реплик, вам нужно быть как минимум clusterAdmin или иметь роль root.
В MongoDB Atlas создайте пользователя как atlasAdmin
И используйте Atlas API для изменения реплики. установить конфигурацию.
Недоступно для бесплатного уровня (экземпляр M0)
blockquote>
7 ответов
Интерфейсы обычно приводят к небольшому снижению производительности (однако это может измениться в зависимости от используемого языка / среды выполнения):
- Методы интерфейса обычно реализуются через виртуальный вызов компилятора. Как указывает другой пользователь, они не могут быть встроены компилятором, поэтому вы теряете этот потенциальный выигрыш. Кроме того, они добавляют как минимум несколько инструкций (переходы и доступ к памяти), чтобы получить правильный ПК в сегменте кода.
- Интерфейсы на нескольких языках также подразумевают граф и требуют DAG (направленный ациклический граф) правильно управлять памятью. В различных языках / средах выполнения вы действительно можете получить «утечку» памяти в управляемой среде, имея циклический граф. Это создает большую нагрузку (очевидно) на сборщик мусора / память в системе. Остерегайтесь циклических графиков!
- Некоторые языки используют интерфейс в стиле COM в качестве базового интерфейса, автоматически вызывая AddRef / Release всякий раз, когда интерфейс назначается локальному или передается по значению функции (используется для управления жизненным циклом). Эти вызовы AddRef / Release могут складываться и быть довольно дорогостоящими. Некоторые языки учли это и могут позволить вам передать интерфейс как 'const', который не будет генерировать пару AddRef / Release, автоматически сокращая эти вызовы.
Вот небольшой пример циклического графа, где ссылки на 2 интерфейса друг друга, и ни один из них не будет автоматически собираться, поскольку их счетчики ссылок всегда будут больше 1.
interface Parent {
Child c;
}
interface Child {
Parent p;
}
function createGraph() {
...
Parent p = ParentFactory::CreateParent();
Child c = ChildFactory::CreateChild();
p.c = c;
c.p = p;
... // do stuff here
// p has a reference to c and c has a reference to p.
// When the function goes out of scope and attempts to clean up the locals
// it will note that p has a refcount of 1 and c has a refcount of 1 so neither
// can be cleaned up (of course, this is depending on the language/runtime and
// if DAGS are allowed for interfaces). If you were to set c.p = null or
// p.c = null then the 2 interfaces will be released when the scope is cleaned up.
}
это означало бы снижение производительности
Дизайнер должен иметь возможность доказать свое мнение.
Кодирование интерфейса всегда будет проще, просто потому, что интерфейсы, если все сделано правильно, намного проще. Ощутимо легче написать правильную программу, используя интерфейс.
И, как гласит старая максима, легче заставить правильную программу работать быстро, чем заставить быструю программу работать правильно.
Итак, запрограммируйте интерфейс, получите все работает, и затем проведите профилирование, чтобы помочь вам удовлетворить любые ваши требования к производительности.
«По-видимому, нет существенной разницы в исходной стоимости статического вызова, вызова экземпляра, виртуального вызова или вызова интерфейса»
Это зависит от того, какая часть вашего кода будет встроена или нет во время компиляции, что может повысить производительность примерно в 5 раз.
Также требуется больше времени для кодирования интерфейсов, потому что вам нужно закодировать контракт (интерфейс), а затем конкретная реализация.
Но правильное решение всегда требует больше времени.
Во-первых, я бы сказал, что общая концепция такова, что время программиста обычно более важно, и работа против реализации, вероятно, потребует гораздо больше работы когда реализация изменяется.
Во-вторых, с правильным компилятором / Jit я бы предположил, что работа с интерфейсом занимает смехотворно небольшое количество дополнительного времени по сравнению с работой против самой реализации. Более того, такие методы, как шаблоны, могут препятствовать запуску кода интерфейса.
В-третьих, процитирую Кнута: «Мы должны забыть о небольшой эффективности, скажем, примерно в 97% случаев: преждевременная оптимизация - это корень всех зол».
Так что я бы предложил сначала хорошо кодировать, и только если вы уверены, что есть проблема с интерфейсом, только тогда я бы рассмотрел возможность изменения.
Также я бы предположил, что если бы это падение производительности было правдой, большинство игр не Я использовал подход ООП с C ++, но это не тот случай, эта статья немного подробно описывает это.
Трудно говорить о тестах в общем виде, естественно, плохая программа может потратить много времени на плохих интерфейсах, но я сомневаюсь, что это верно для всех программ, так что вам действительно стоит взглянуть на каждую конкретную программу.
На мой взгляд, вся тяжелая работа, связанная с графикой, всегда перекладывается на GPU. Это освобождает ваш процессор для других вещей, таких как выполнение программы и логика. Я не уверен, есть ли снижение производительности при программировании интерфейса, но если подумать о природе игр, их не нужно расширять. Возможно, определенные классы, но в целом я бы не подумал, что игру нужно программировать с учетом расширяемости. Так что вперед, код реализации.
Я думаю, время жизни объекта и количество создаваемых вами экземпляров даст грубый ответ. .
Если вы говорите о чем-то, что будет иметь тысячи экземпляров с коротким временем жизни, я бы предположил, что это, вероятно, лучше сделать с помощью структуры, а не класса, не говоря уже о классе, реализующем интерфейс.
Я не могу себе представить, чтобы что-то более похожее на компоненты, с небольшим количеством экземпляров и средним или долгим сроком службы.