Влияет ли импорт из пакета enum Java из-за проблем с производительностью? [Дубликат]
Самый короткий ответ, вероятно, будет «определение - исполнение», поэтому весь аргумент не имеет строгой точки зрения. В качестве более надуманного примера вы можете привести следующее:
def a(): return []
def b(x=a()):
print x
. Надеюсь, этого достаточно, чтобы показать, что не выполнять выражения аргументов по умолчанию во время выполнения инструкции def не просто или не работает, т. е. смысл, или и то, и другое.
Я согласен с тем, что при попытке использовать конструкторы по умолчанию, это будет gotcha.
5 ответов
повлияет на производительность моего кода (например, программа будет медленнее)?
Нет, это не повлияет на производительность вашего кода.
Бинарные файлы (файлы классов) не увеличиваются в размере, поскольку импорт not реализован с помощью любого механизма вырезания и вставки.
Это просто синтаксический сахара, чтобы избежать необходимости писать, например
java.util.List<java.math.BigInteger> myList = new java.util.ArrayList<java.math.BigInteger>();Вот небольшой тест, демонстрирующий это:
aioobe@e6510:~/tmp$ cat Test.java import java.util.*; public class Test { public static void main(String[] args) { List<Integer> myInts = new ArrayList<Integer>(); } } aioobe@e6510:~/tmp$ javac Test.java aioobe@e6510:~/tmp$ md5sum Test.class 523036e294b17377b4078ea1cb8e7940 Test.class(изменение
Test.java)aioobe@e6510:~/tmp$ cat Test.java public class Test { public static void main(String[] args) { java.util.List<Integer> myInts = new java.util.ArrayList<Integer>(); } } aioobe@e6510:~/tmp$ javac Test.java aioobe@e6510:~/tmp$ md5sum Test.class 523036e294b17377b4078ea1cb8e7940 Test.classЯвляется ли логика импорта в Java такой же, как и в C?
Нет,
#includeявляется директивой препроцессора и реализуется с помощью cut-and -пастевый механизм.
-
1Не идет к -1, но это может быть больше, чем синтаксический сахар. – corsiKa 26 February 2011 в 07:20
-
2Как что? Я понимаю, что с импортом vs без импорта будет выглядеть по-другому только до IR в компиляторе. (Посмотрите мой пример в обновленном ответе.) – aioobe 26 February 2011 в 07:22
-
3+1 Мне нравится использование md5sum для управления домашним домом. – user 26 February 2011 в 07:47
-
4@pst, объяснение того, что будет иметь постоянный пул – bestsss 26 February 2011 в 10:54
-
5@bestsss Это было бы приятным дополнением для более целостного ответа, но трудно утверждать, что это «бит-идентичный вывод». – user 26 February 2011 в 18:42
Это не повлияет на скорость выполнения вашей программы.
Это может повлиять на скорость компиляции вашей программы.
Если вы import java.util.*; загрузите весь пакет java.util в компилятор, что может увеличить время компиляции, когда вы .* весь пакет для одного использования (хотя вы должны выполнить некоторые профилирования, если это будет проблемой .)
Помимо проблем с компиляцией потенциала , не забывайте учитывать проблемы читаемости. Как правило, я (и люди, с которыми я разговаривал) нахожу import pack.age.Class; более читабельным, чем import pack.age.*; - поговорите с вашей командой, прежде чем принимать решение об этом.
Но логика за ним сильно отличается от #include и не раздувает код. Вы можете оказаться в более чем необходимо, поскольку вы включаете банки с зависимостями, но это, вероятно, не большая проблема.
-
1Попытка сохранить время компиляции в виду, когда писать код кажется неудачной идеей. Вы идете на бенчмарк, выясните, есть ли какая-то существенная разница и вернитесь с вашими результатами :-) – aioobe 26 February 2011 в 07:29
-
2Для скоростей? Да. javaperformancetuning.com/news/qotm031.shtml Для синхронизированного? Во втором есть один дополнительный байт-код, потому что есть синхронизированная инструкция, где, как и первая, она запекается в модификаторах метода (что теоретически может сделать или сломать встроенный / JIT, но невероятно маловероятно). – corsiKa 26 February 2011 в 07:39
-
3
-
4"может значительно увеличить время компиляции" является утверждением факта. Используя «сильно», он также предъявляет требование величины. Если вы хотите представить его как что-то для расследования и не претендовать на величину, вы должны написать «может повлиять на время компиляции». вместо. Утверждение дается без достаточных доказательств и может быть ложным. Фактическая неточность - это единственная причина, по которой я отвечаю за ответы, потому что вводящий в заблуждение ответ хуже, чем никто. – meriton 27 February 2011 в 19:16
-
5Что касается того, что Паскаль не получает нисходящего потока, это потому, что он просто утверждает: « возможно будет больше ( бит ) дольше для компилятора & quot ;. & Quot; сильно & Quot; более чем "бит" и "может" более чем "вероятно". И, кстати, если бы вы знали об этом дублирующем вопросе, почему вы не ссылались на него? – meriton 27 February 2011 в 19:29
import не замедляет вашу программу. Лучше иметь разные типы classes в разных packages и импортировать их по мере необходимости. Улучшает читаемость кода.
-
1что вы подразумеваете под «лучше иметь разные типы классов в разных пакетах»? благодаря – newbie 26 February 2011 в 07:31
-
2@newbie Я имел в виду, что это хороший дизайн, чтобы иметь разные классы в разных пакетах и импортировать их по мере необходимости. Вероятно, это напрямую не связано с вашим вопросом. – fastcodejava 27 February 2011 в 00:32
... повлияет ли это на производительность моего кода
Не в малейшей степени. Фактически, скомпилированные классы (с использованием импорта или нет) будут идентичными. Импорт - это просто синтаксический сахар, который позволяет использовать более короткое имя для внешнего класса или (со статическим импортом) класса в исходном коде. Другими словами, он позволяет вам писать:
Map map = new HashMap();вместо
java.util.Map map = new java.util.HashMap();Это все.
Существует потенциально небольшой (крошечный ) разница в сбор времени. Но AFAIK, что-то вроде
import java.util.*;, НЕ приводит к тому, что все классыjava.utilзагружаются компилятором. Скорее, он просто добавляет имена классов в таблицу символов.Сказав это:
- Ненужные импорты - плохая идея, потому что они заглушают код и могут ввести в заблуждение кого-то, читающего код.
- Импорт подстановок (
.*) может привести к неожиданным столкновениям.- Множество людей (включая меня) не любят шаблон импортируется, потому что они предпочитают видеть список используемых фактических классов.
Является ли логика импорта в Java такой же, как и в C?
Нет, это не так.
В директиве C / C ++ директива вводит произвольный код 1 C / C ++ в исходный поток. Это может включать объявления и исполняемые операторы ... которые могут влиять как на производительность, так и на объем исполняемой памяти и размер исполняемого файла.
1 - То есть независимо от того, какие авторы файла include выбрали положить в файл. Это может быть простой метод и класс «подписи», но также могут быть макросами, кодами и другими объявлениями. Вы должны проверить файл, чтобы убедиться.
-
1
-
2Может быть. Это может быть что угодно, что является юридическим кодом. Вот почему они (потенциально) оказывают влияние на производительность, и их необходимо рассматривать в каждом конкретном случае, чтобы определить это. Понимаю? – Stephen C 2 August 2017 в 23:05
-
3Уточнение - это хорошо. Я думал о «произвольном». как «случайный», который он не является. – Matthew Woo 3 August 2017 в 16:45
Импорт не является проблемой. Вы можете импортировать все, что хотите, из пакета, а выполнение вашего кода не будет замедляться. import для удобства, поэтому вы можете использовать более короткие имена.
Классы загружаются, когда их конструктор называется неявным или явно (новый оператор). В случае перечислений это будет когда вы ссылаетесь на имена переименования в вашем коде. Это приведет к загрузке класса (enum). (Вы можете попробовать использовать println в приватном конструкторе enum для эксперимента и посмотреть, когда загружается enum). Загрузка класса требует времени и памяти. Обычно загруженные классы не предназначены для разгрузки.