- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
<?php
class Pet {
protected $name;
public function __construct($name) {
echo "Setting name to " . $name . "\n";
$this->name = $name;
}
public function eat() {
echo $this->name . " is eating.\n";
}
}
$var = 30;
$a_pet = new Pet("Spike");
$a_pet->eat();
?>
---
<?php
function Pet__construct(&$objInst, $name)
{
echo 'Setting name to ' . $name . '
';
$objInst['name'] = $name;
}
function Pet_eat(&$objInst)
{
echo $objInst['name'] . ' is eating.
';
}
$Pet = array('__vars' => array('name' => null));
$var = 30;
$a_pet = array_merge($Pet['__vars'], array('__type' => 'Pet'));
Pet__construct($a_pet, 'Spike');
Pet_eat($a_pet);
А интересно, этому есть реальный пример применения (для совместимости, например), или это потому что могу?
А если серьёзно, то тут какая-то переголова: мы создаём ненужный экземпляр $Pet в качестве рыбы, и при создании нужных экземпляров копируем его (точнее, мержим с новыми данными). В случае, если нам нужен синглтон, у нас будет два экземпляра вместо одного. Пахнет прототипным программированием из жопоскрипта.
А в «PHP» даже обычные функции ищутся в глобальной таблице функций по имени. Так что в «PHP» можно не думать о способах вызова подпрограмм, потому что всегда будет хуёво.
>> и на шарпе
Интересно. Следует ли из этого, что кишки ООП в «C#» и в «Java» устроены по-разному? Какие принципиальные различия ООП в этих языках?
>Интересно.
В C# метод по-умолчанию не виртуальный, виртуальность надо заказывать явно
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/virtual
Это позволяет мне думать, что невиртуальный метод может быть известен уже на момент компиляции.
В Java же все методы виртуальны (хотя наверное final не виртуальны, если не забывать их писать)
Javaбялди соснули
invokevirtual не смотря на final. Може, джит чото и может, но не JavaC
Очень смешно конечно, что там везде int, и размер его фиксирован в спеке, и никогда не поменяется.
Через 20 лет компы будут 256-ти битные, а инт у JVM все еще будет 4, лол
https://docs.oracle.com/javase/specs/jvms/se13/html/index.html
Но жабоёбы соснули, да.
UPD: ораклы охуели, новая спека «Access Denied» выкидывает. Пидорасы.
https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.10.1.9.invokedynamic
Груверы очень радовались: у них все стало чутьменьше томрозить
> The difference between the invokespecial and the invokevirtual instructions is that
> invokevirtual invokes method based on the class of the object. The invokespecial
> instruction is used to invoke instance initialization methods as well as private
> methods and methods of a superclass of the current class.
другими словами, invokespecial как раз-таки вызывает методы без динамического биндинга. Какая компиляция )))
https://github.com/mtumilowicz/java-bytecode-invokespecial
>Virtual (and interface) invocations are often demoted to "special" invocations, if the class hierarchy permits it.
Как видно из моего примера -- джавак так не делает: вызов финального метода у финального(!!!) класса он invokevirtual.
invokespecial там только конструктор
зы: ладно, всё, я почитаю и вернус
В хорошем коде 99.9% методов -- финальные. За наследование реализации и переписку ейных методов надо пиздить сковородкой. Это очень плохой паттерн.
И JVM каждый раз луркает в таблицу (у правда она может луркнуть в момент загрузки класса конечно, всё таки налету там ничего не меняется, это не JavaScript).
Но всё равно пахнет говном.
Хотя вообще тот факт, что методы по умолчанийу виртуальны пахнет гавном еще больше
Есть реальные примеры мейнстримовых языков, в которых можно легко и просто шарить реализацию без наследования? Сразу скажу, что всякие там default implementation как в Свифте не предлагать: максимум, что ты на них построишь, это синтетику или совсем уж примитивные вещи.
https://kotlinlang.org/docs/reference/delegation.html
Собственно, наследование почти всегда можно заменить делегированием, но обычно для этого нет сахара, и нужно писать руками много бойлерплейта. Ну вот в Котлине не нужно.
Так же это не нужно во многих скриптовых языках, но это отдельная история.
Ты понимаешь в чем проблема класса, у которого наследник переопределил какие-то методы, или раскрыть тему?
А вот примеры на Котлине я нихуя не понял. Судя по вики, Котлин это чуть ли не единственный йезык, где это чудо поставляется с батарейками, но о чём это, я всё равно не допетрил.
Попробую объяснить котлиновое делегирование
Все, или только те, что определены в Bird?
?
Ну так, мило. Но super уже не позовёшь, например.
Но сам цимес ты оценишь, когда ты добавишь в интерфейс два метода, а третий удалишь. И все 18 его реализаций в коде тебе не нужно будет править.
super сам зовется, если ты занаследовался:)
В общем наследоваться надо (имхо) если ты реально являешься частным случаем чего-то, а ради шаринга кода лучше делегироваться, даже у Фаулера был такой рефукторинг
По сути даже в твоём примере выше получается, что и вьюха, и контроллер конформят один и тот же интерфейс, толлько чтобы работал этот delegation, если я правильно понял. Похоже на абьюз.
Запросы от клиента поступают в контроллер. Клиент знает, что он хочет вывести какой-то текст, или что хочет сохранить данные.
Методы для вывода текста есть в интерфейсе, допустим, TextView. А для сохранения в Saver.
Котроллер реализует оба интерфейса.
Клиент получает иинстанс контроллера, и работает с ним.
Под капотом контроллер сохраняет данные сам, а запросы на вывод пересылает в вьху. То-есть один интерфейс он реализует сам, а другой делегирует. Причем любой вызов он может в любой момент переопределить.
Без делегейта мне пришлось бы или писать бойлерлпейт, или реализовывать паттерн Команда -- такой класс, который инкапсулирует все требования клиента, и передавать его инстанс во вью (ну по сути как forwardInvocation, но вручную)
Что там под капотом-то происходит? И что делать, если я хочу, чтобы Derived не Base конформил, а какой-то интерфейс, частично совпадающий с Base по сигнатурам?
именно.
>Что там под капотом-то происходит?
реализуются все методы типа
> интерфейс, частично совпадающий с Base по сигнатурам?
А он как-то связан с Base, или просто методы так же называются?
Можно использовать рефлексию, но это очень некрасиво, медленно, и не нужно
На самом деле там динамического питуха гораздо больше, чем в скрипте. Жабьей рефлексией можно менять всё что угодно, включая байткод любых методов и вообще классов (включая те, что в стдлибе), хакать жабокод очень приятно. Правда, это всё очень по-жабьему многословно, но зато нет такого, что из замыкания никакими способами нельзя вытащить захваченные переменные (дядя ПИ недавно замечательный пример приводит). И именно поэтому я за «Java» (в контексте динамичности).
Сначала тупое
код
Теперь добавляем виртуал
и ты не поверишблядь!
Внимане на строку IL_0006
Было call, стало callvirt.
Так что жавабляди соснули у шарпеев. Ну, им не в первой.
Hotspot с лёгкостью уже лет 10 как инлайнит виртуальные методы.
1. https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
2. https://shipilev.net/blog/2015/black-magic-method-dispatch/
3. https://shipilev.net/jvm/anatomy-quarks/16-megamorphic-virtual-calls/
4. https://www.nurkiewicz.com/2013/01/how-aggressive-is-method-inlining-in-jvm.html
Ещё была классная статья с бенчами инлайна джвух наследников. Не могу сходу найти.
То-есть это JIT должен доказать, что метод всегда один и тот же, и тогда его можно инлайнуть.
При этом это знание можно получить на уровне компиляции, и избавить JIT от ненужной работы. Почему этого не было сделано? Чтобы не вводить еще один байткод?
Нет.
Он обходится без виртуальных функций даже когда два потомка и соответственно два метода. Чего C# не умеет в принципе.
См. ссылку №1
>Methods are often inlined. This increases the compiler's "horizon" of optimization.
>Static, private, final, and/or "special" invocations are easy to inline.
>Virtual (and interface) invocations are often demoted to "special" invocations, if the class hierarchy permits it. A dependency is registered in case further class loading spoils things.
>Virtual (and interface) invocations with a lopsided type profile are compiled with an optimistic check in favor of the historically common type (or two types).
> эта задача переехала в JIT, верно?
jit ничего не доказывает. Он собирает статистику. И если метод вызывается всегда только на одном классе — его инлайнят.
То есть инлайн будет происходить, в случае когда есть несколько наследников, но вызывается только один или два.
Язык и не может этого уметь. Ты говоришь же об оптимизации JIT.
Умеет ли это JIT CLR я не знаю.
>Static, private, final, and/or "special" invocations are easy to inline.
Ну слава богу! Значит, хотябы JIT это понимает.
Кстати, а что будет, если потом вызовется всё таки другой метод?
И как заинлайнить метод на 900 строк в 900 мест?
То, что JIT это умеет, это великолепно конечно.
Но у нас в коде есть довольно четкое понимание, что метод не виртуальный, и диспатчить его через виртуальную таблицу не нужно.
Компиляторы C++ и C# умеют этим знанием пользоваться, а компилятор Java -- нет.
Насколько сильно это бьет по перформансу я не знаю (видимо вон надо брать шипилевский профайлер, и проверять.
Зы: кажется, я понял, что это может попорить ABI
https://govnokod.xyz/_26465/#comment-513821
Признайся. Ты не читал ни одну из данных мною ссылок.
Будет деоптимизация.
>И как заинлайнить метод на 900 строк в 900 мест?
Компилятору виднее. Если он решит что этого не стоит делать, то инлайна может и не случиться.
А ещё эти сволочи забрали у погромиста ключевое слово inline. Гады, ненавижу.сраказм
>inline
и register, в общем я тебя понял.
Кстати, в котлине есть inline, он позволяет делать reified
https://kotlinlang.org/docs/reference/inline-functions.html#reified-type-parameters
В мире джавашков, это принято считать не багом, но фичей.
Типа мы оптимизируем на месте, под конкретные машины и конкретные наборы классов.
Ну в целом «оптимизировать» байт-код виртуальной машины с jit, это как у реальной машины пытаться на ходу руками крутить колёса, чтобы та ехала побыстрее.
Из №4
Important remark is that it's the JVM, not the compiler. javac is quite conservative when producing bytecode and leaves all that work onto the JVM. This design decision turned out to be brilliant:
* JVM knows more about target environment, CPU, memory, architecture and can optimize more aggressively
* JVM can discover runtime characteristics of your code, e.g. which methods are executed most often, which virtual methods have only one implementation, etc.
* .class compiled using old Java will run faster on newer JVM. It's much more likely that you'll update Java rather then recompile your source code.
Проехав сотню-другую другую километров на квадратных колёсах, JIT решил, что пора бы их оптимизировать и поменять на круглые.
С тегом: #так_говорил_Борманд
Вкупе с этим:
https://govnokod.ru/26356#comment521479
«Оптимизировать байткод - это как опрыскивать говно духами.» ⓒ
У меня нету статистики по перформансу, вполне может быть что я доебался до спичечного коробка.
Но когда у тебя есть проект размером с Intellij Idea в котором каждую секунду вызываются десятки тысяч методов, может быть даже маленькая оптимизация бы помогла. Черт его знает когда там JIT раздуплится, и что-то починит.
И да: сурс мы пересобираем чаще, чем выходят новые джавы.
Но аргумент про "JIT работает лучше, потому что знает конкретную архитектуру" я слышал от .NET, и может быть и правда смысл есть.
Типа JIT узнает, что у конкретного процессора есть какая-то суперкрутая иинструкция, и заюзает ее. Может быть такое?
Ага.
Я тоже его слышал в далёком 2003.
Поставил я себе тогда этот «.NET».
Мама дорогая, как же оно тупило.
Но маркетинг был прекрасен:
«Много языков», «одна платформа», «оптимизация под ваш процессор».
Я тогда померял и VB.NET сливал по пирфомансу даже старому VB6.
Причём вроде даже в P-code. А то что шарпик сливал VC++, думаю и так очевидно.
Впрочем с тех пор и жаба сильно ускорилась и .NET тоже.
И эта идея про оптимизацию во время установки софта мне очень нравится - не надо 100500 бинарей под разные рахитектуры, но при этом можно заточить код под конкретный проц и даже под конкретные либы которые сейчас стоят в системе.
Знаю одну такую оптимизацию. Популярна во {фри,нет}бзди, линукс генте и пр (думаю что и в арче)
Прописываешь в make.conf CFLAGS и CPUTYPE, и ставишь софт:))
Реальная оптимизация «под конкретную архитектуру» и задачу, это профилирование ( -fprofile )
Однако довольно мало либ поддерживают профилирование прямо из make.
libx264 один из примеров.
-mcpu=native -march=native наше всё.
Я так делаю, НО ИСКЛЮЧИТЕЛЬНО для тех либ и программ, которыми пользуюсь и где мне наверняка нужен пирфоманс.
Вот там приводились такие числа, что для большинства программ, собранных для i386, прирост перформанса был не выше двух процентов. Так что в целом игра не стоила свеч, кроме высоконагруженного софта конечно
Тогда не было столько инструкций.
SSE, MMX. Ну и немного 3DNow.
>2001
SSE2 либо не вышел, либо только-только и все сидели на P3 и Атлонах. И это был на тот момент наиболее массивный набор новых комманд. 140+ инструкций, емнип.
Сейчас же SSE2 — baseline для x64. Под него можно собирать все 64-битные пакеты.
А после него идут: SSE3, SSSE3, SSE4.1, SSE4.2 (строки) AVX, AVX2, BMI, FMA, AVX512 (с кучей профилей)
Простор для оптимизаций гораздо шире.
Бля, сумасшедшие какие-то…
во-первых собирать из сырцов можно с помощью системы портов/пеекджей/портеджей, и тогда не надо ебаться
во-вторых в время описываемых событий много чего в бунарных пакетах могло и не быть
и наконец есть прекрасный слакварь со слакбилдом, где ебаться как бы и не надо, а все же надо
ну и наконец когда у тебя на сервере 486 с 8-ю метрами памяти (это нормально для 2001-го года), то тебе может хотеться не грузить в память лишний код
Спасибо, не надо, я лучше бинарь поставлю.
Именно по-этому я за указанные выше порты и их вариации: собирается всё само, зависимости сами приезжают, тебе нужно только сказать make.
Правда, сборка, например, иксов с KDE -- дело не быстрое, можно устать ждать.
Проснись, ты обосрался даже проецируя свой цєлерон под Шиндошс XP образца 2020 года.
Даже прыщепердолики в 2001 давно повыкидывали на помойку такие высококопроизводительные платформы класса Писюк
А вот ffmpeg кажется что в теории может стать лучше
Да. И то. Ну 3-5% максимум что я выжимал.
Там же ручного ассемблера очень много.
Самое лучшая оптимизация это просто собрать его шлангом. И сборка быстрее чем gcc. И бинарник оптимизированей.
Причём --cpu=native --extra-cflags="-march=native" --extra-cxxflags="-march=native" даже немного просаживало пирфоманс при использовании clang.
Почему так, я не знаю до сих пор.
В ffmpeg code-base огромный, на старых процессорах он довольно долго собирается.
Как это всё профилировать, хз.
НУ, кроме сборки специфичного для него кода
Дело в том что много программ, которым нужна скорость (вроде ffmpeg) давно вызывают написанный ручками ассемблер, специфичный для конкретной архитектуры.
Процессор детектится в рантайме и на лету подставляются указатели на оптимальные для поддерживаемого набора команд функции.
Компилятор не очень тут поможет.
А программы, которым не нужна скорость, и пересобирать бессмысленно.
А только на самые проблемные места, и самые частоиспользуемые кодеки.
Страшно заточенный декодинг H.264 сильно не ускорит.
Но если какая-то экзотика малооптимизированная или фильтры, коих там тысячи.
То благодаря такой сборке, и более новому компилятору можно выгадать до 10% скорости.
>зачем что-то собирать под конкретную арихтектуру
Профит есть. Всё-равно там сишка есть.
> зачем что-то собирать под конкретную арихтектуру
Я руками собирал ffmpeg, когда его из убунты выпилили.
Плюс самая свежая версия, плюс своя сборка быстрее.
хм
я для слаки тоже собирал (правда из слакбилдов всё таки), а то там даже H264 не работал
В 14 LTS эти анскильные отбросы завезли avconv/libav.
Я уже травил стори про это:
https://govnokod.ru/26372#comment522890
https://govnokod.ru/15663#comment225480
>ffmpeg version 3.4.6-0ubuntu0.18.04.1
Тоже не годится. Гавно старое.
Везде 4.2 давно.
Нидернмайер раньше на все жалобы так и отвечал: use CVS, use git.
говно правда, ждем 20.04:)]
зы у мну 18
Я вижу.
>ну видимо вернули обратно уже
Это происходило с большим скрипом, срачем и жуткими проблемами.
Жаль потерял ссылку (или её удалили) на страницу где был целый ПЛАН по переводу убунты обратно.
Добрый день.
Как раз профилировал шлангом одну либу.
Прирост пирформанса составил около 3%.
-O3 -DNDEBUG -fno-exceptions -fno-rtti в обоих случаях.
А flto не помогло. Там что-то около 0.5%, в пределах погрешности.
Уменьшение перепитуха компенсируется раздуванием кода и кеш-промахами icache.
скептики посрамлены
Там ещё может быть от 1% до 5% за счёт AVX2 и прочих -mnative.
Ну кому-то и 3% это ни о чём. Это сколько же нужно пирдолиться. Профайленный билд собирать в 2 раза дольше по времени, плюс нужно написать руками скрипт для двухпроходной сборки.
А вот например для Гугла даже 1% и то хорошо.
Make flto great again.
https://www.phoronix.com/scan.php?page=news_item&px=Machine-Function-Splitter
https://lists.llvm.org/pipermail/llvm-dev/2020-August/144012.html
особенно, когда речь о лишь 3%
видимо, стоит обсуждать случаи, когда горизонтальное масштабирование не вариант, и вообще никакое масштабирование не вариант, но их не так и много
Ну это разовое. А вот семплы для профайлинга поддерживать в актуальном состоянии, чтобы они реальные данные отражали - это уже всю жизнь.
Ну не для всех применений.
В моей практике даже на рандомных/коротких семплах профит довольно ощутим и замеряем.
Кто ATLAS не собирал — жизни не видал. To proceed with a random ATLAS tuning in the face of CPU throttling, you can throw the configure flag: --cripple-atlas-performance.
GENTOO
Я ведь ждал царского пирфоманса, SSE2 всяких, а получил Microsoft™ Java, которая сливала даже Бейсику!
Я ради интереса наформошлёпал обычное оконное приложение. Запустил, и оно сожрало 50Мб памяти!
ПЯТЬДЕСЯТ МЕТРОВ. Для понимания у меня тогда было 512Мб, и это было МНОГО, т.к. большинство тогда сидело на 256.
Хорошо что я .NET ломаный взял. А кто-то ведь мог и купить это говно.
Я дотнет первый раз потрогал году в 2007-м, это был .NET 2.0 и C# тоже 2.0 (и решарпер, лол), студия была 2005.
WinForms довольно неплохо работали, и ASP.NET тоже, но конечно памяти у меня был где-то гиг, и проц какой-то на 775-м.
Но студия запускалась вечность.
Теперь у меня Студия 2017 и Coffe lake i7, а студия все равно запускается вечность
Ага. Я субъективно помню что всё дико тупило. Ставилось ну очееень долго.
>Теперь у меня Студия 2017 и Coffe lake i7, а студия все равно запускается вечность
Между прочим IDE от МS раньше считались очень шустрыми.
VB и VC на слабых машинах грузились пулей по сравнению с Дельфями и Быдлером.
Но потом в Майкрософт переманили главного борландовца и понеслась.
>JVM в ту пору тоже не супер быстро работала в каком-нить pentium 3 tualatin:)
Java тогда считалась самым медленным языком вообще. Но кроссплатформенным.
Вот как выглядела визуал-студия мечты
http://img.xz7.com/up/2016-12/2016122883447.jpg
З.Ы. Обидно, что MSDN сейчас скатили в какую-то хуйню с битыми ссылками и корявым переводом.
А кто помнит Source safe? А spy++?
Да, помню. Но source safe дрянь, не греющая душу.
А аналог spy++ я и сам писал на winapi, причём куда информативнее.
там была пессимистичная блокировка: ты чекаутнул файл -- и больше никто не может его забрать
может был и другой режим, но я помню именно такой
Благо у нас CVS был. Я на православном CVSNT года до 2007 просидел.
Вот именно такое чувство от этого говёного .NETа было.
Тупило вообще всё: инсталл, хелп, IDE и написнаные на нём программы.
После VS 6.0 (немного проапдейченой Visual Studio 1997) это казалось просто каким-то тошнотворным тормозным ужасом.
.NET это первая фрустрация от MS, а второй была Виста.
Причём оба были долгостроями, и в итоге эталонный багор.
Проверял свежие версии на Sandy Bridge питухе, на Coffee Lake питухе, и на Core 2 Duo питухе в марте 2020.
Причём вот он нормально работает с файлами гига на 3-4, но периодически какие-то фризы по полминуты, как-будто gc работает.
* Тормозит, если включен спеллчекер
* Тормозит, когда меняется длина количества строк (проскроллил с 999 на 1000 строки)
* Тормозит, когда длинные строки не разбиваются \n и включён автоперенос
>У меня на ~6МБ уже начинает тормозить.
А гоcть за vim совсем не зря топил.
Ну да, проверил, vim на 5 гиговом файле вполне сносно работает. По крайней мере поиск и чтение. А редактировать такие файлы я и не собирался.
1024-- 15.02.2020 03:23
>Они там поехавшие совсем были?
>Или компьютеры настолько тормозили, что перерисовывать экран после нажатия кнопки было долго?
Ахахахах. Так компьютеры и сейчас ТОРМОЗЯТ.
1024-- 18 минут назад #>>531542 +2
Да вы там поехавшие с суперкомпьютерами. У меня на ~6МБ уже начинает тормозить.
Пока анскильные отбросы ждут ответа от редактора «What You See Is What You Get».
Настоящие Цари с vim и ed на 486 обгоняют суперкомпьютеры.
Обмажутся своими экмаскриптами и электронами, а потом жалуются, что редактор на 6МБ текста тормозит.
Скриптуха бы сдохла на первом мегабайте.
Я уже говорил, что «problem with these editors is that Real Programmers consider "What You See Is What You Get" to be just as bad a concept in Text Editors as it is in women»
Но в целом проблема всех WYSIWYG-адептов в том, что они домохозяйки, которые начинают рассуждать о матчасти, консоли, линуксе и прочем.
Хотя, казалось бы - зачем?
Они просто показывают свои мечты, своё желание быть чем-то большим, нежели веб-макака.
Поэтому никто тебе слово не скажет, если ты будешь говорить правильно "моя WYSIWYG там круто, кукареку".
Но проблема не в этом. Проблема в том, что каждый сектант с очередным недоредактором прибегает и рассказывает о том как же vim/less/ed/teco ненужны и как он всех победил.
На этом фоне и развиваются все эти комплексы и они желают доказать всему миру, что вот они не говно.
И пропаганда это так же использует.
Она как-бы даёт веб-макаке недоредактор на котором она может насрать хелворд и даёт возможность сообщить "дак я же как teco", "дак я же как vim".
Чего рядовой адепт сделать не может. Хотя они и пытались.
Все эти Notepad++ сектанты - это вчерашние адепты notepad.exe — ещё вчера они орали, что консоль — говно, а MS Word убьёт vim и вообще лучше vima.
Очевидно, что абсолютно неважно как человек действует тогда, когда он мнит себя хозяином и гладит холопа.
Всё проявляться тогда, когда нужно отвечать и обосновывать.
И вот он спокойно сидел пока были файлы на 6 килобайт и начал обмазываться говном и тебя им закидывать тогда, когда ты предложил открыть большой файл.
WYSIWYG-сектант просто мразь. Сектант попросту не осознаёт своей деятельности.
Он может свято верить в том, что валять в говне и кидаться говном - это и есть ответ и аргументация.
Важно показать, что это не так.
https://tsar1997.blogspot.com/
Теперь аккуратно совершай возвратно-поступательные движения рукой.
а чем можешь похвастаться ты?
Это не новость:
https://govnokod.ru/26351#comment521224
И понимаю что Царь как всегда прав.
Гость топивший за vim тоже достойный боярин. А божественные редакторы опять плеснули мочи в рожи WYSIWYG-сектантов.
А teco, ed, ex, vim, less написаны на божественной Сишке!
В этом всё дело.
«Large Text File Viewer» тоже не тормозит на гигабайтах.
Специально написан для многогигабайтных файлов.
Собссно, парсер именно и тормозит кмк
Плюс он очень хуёво обрабатывает крупные файлы с непечатными символами. NP++ их отображает как псевдосимволы (HEX-код в прямоугольнике), и когда их много — всё начинает адово тормозить. Подозреваю, что на каждую отрисовку такого символа он перерисовывает весь предыдущий текст, вот и получается квадрат.
🙁
просто проверь!
Я гигабайтные логи смотрю строго через less.
Пайпы, нумерация строк, поиск, синтаксис такой же как у vima. Полёт отличный.
Короче царские редакторы опять слили в хламину гыгыкавших анскильных мразей.
F3 же. Ну хотя с 64-битным фаром может быть и F4 прокатит...
F3 вообще огонь.
> на трех CD
Да у нас же тут инторнет-консервы!
Если постоянно запущена служба «Microsoft .NET Framework NGEN v4.0.30319_X86» (она же clr_optimization_что-то-там), то всё тупит и вечно мало свободной памяти.
Всё работает намного быстрее, если выключить эту службу и вручную отправлять команду «ngen update» после установки программ. Тогда ресурсы будут потрачены только на перекомпиляцию новых модулей.
Так и в жабе тоже какая-то служба под винду была.
Java Quick Runner или Java Starter, что-то такое.
https://cecomputerexpertise.files.wordpress.com/2010/10/gpo-java-quick-starter1.png
ngen от Sun.
Зачем? Зачем?
Какие знания?
А если новую реализацию класса подгрузят класслоадером?
А если cglib сгенерит новый класс на лету?
А если просто подложат jar с классом-наследником?
Если класс не финальный нельзя делать такие допущения.
Знания о том, что финальный метод класса не может быть переопределен.
>А если новую реализацию грузят класслоадером?
Валидный кейс. А что сделает джит со своим инлайном? Выкинет?
>Если класс не финальный нельзя делать такие допущения.
Окей, пусть бы это работало только для финального класса. Но ведь и для него нет специальной инструкции.
С другой стороны финальность класса могут поменять, и тогда получится что надо перекомпилировать клиента: ABI сломается
invokespecial недостаточно специальна?
Интересно.
А старые версии javac вроде как превращали private final в invokespecial.
По крайней мере в JLS раньше так и писали
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html
invokespecial
Invoke instance method; special handling for superclass, private, and instance initialization method invocations
Но раньше там целое объяснение было почему именно invokespecial на приватных методах.
Но стоит снять private, как станет invokevirtual
Блять, вот как же я люблю оракл. Ссылка на баг, почему они поменяли invokespecial на invokevirtual
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=7160765
https://blog.overops.com/oracles-latest-java-8-update-broke-your-tools-how-did-it-happen/
Я же точно помню, что раньше private превращался в invokespecial.
Release 8u20
Area: Specification / vm and HotSpot
Standard/Platform: Java SE 8
Synopsis: The verification of invokespecial instructions has been tightened so that only an instance initialization method in the current class or its direct superclass may be invoked.
RFE: 7160765
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/enhancements-8.html
Действительно, зачем нам писать нормальный байткод?
> А если cglib сгенерит новый класс на лету?
Пусть жит с этим и разбирается. Со стороны байткода никаких проблем нет.
Там еще и статика вынуждена каждый раз искать вызываемый метод. Какой late static binding )))
https://v3toys.ru/index.php?nid=88390
Ничего обычного, проходите дальше
две полоски -- это "доигрался!"
у меня жена от 1 (одного) ребенка вешается и больше под страхом расстрела не хочет (может, через эн лет одумается)
сюжет идиократии напоминает
Наверное, это индивидуально
Я думаю, мне бы напомнили.
ты только на госуслуги иногда заходи, они синкают исполнительные производства
когда у тебя погодки, это вообще пиздец первые годы, смело их вычеркивай из жизни
не все готовы на такие жертвы
но зато через лет 7 ада ты вроде как свободен и снова нормальный человек
+ ребенок это тяжело в общении с ним, приходится опускаться на его высоту, терпеть, терпеть, терпеть
лишаешься ежедневного общения с предыдущим кругом (коллеги, которые плюс минус твоего уровня развития и твоих тем обсуждения, а во дворе мамаши-антиваксы с пивасом и гомеопатией, что с ними обсудить), лишаешься быстрых ачивок (перестаешь делать проекты даже в формате микродостижений) и переходишь на процессный режим работы (день сурка), лишаешься качественного сна, нет перерывов, лишаешься личного пространства (не посрать в одиночку, в душ сходить только когда муж вернулся), и постоянно на нервах, что он где-то найдет приключения (разольет, разобьет и т.д.)
кто-то создан для материнства, и период работы является временным перед семейным, домохозяйским периодом - тем можно и второго и третьего
а кто-то оказывается пиздец не готов, и это испытание
ещё ОЧЕНЬ важно иметь возможность сбагрить ребенка бабушкам или хотя бы тётям или в садик - это дает возможность хотя бы на два часа выдохнуть и перегрузиться
сегодня как раз обсуждалась в соседнем чате тема про сборщик мусора
А уроки проверять? А в кружки водить?
Мальчик до восемнадцати лет думал, что его зовут "заткнись"
> Мальчик до восемнадцати лет
- паспорт же вроде намного раньше получают
– Я Вася, но дома все зовут Наташей!
относительно нормальное время, в которое реально даже сходить помыться!
или в позе креветки в телефоне зависать (это плохо для спины)
чуть дальше, до того, как начинает словами свои мысли выражать - сложнее
изматывающе
потом уже начинает слова, и чуть позже - предложениями
но подступает кризис 3летнего возраста
<вы находитесь здесь>
- а что, правда ситуация настолько плохая с этим, как пишут?
> ещё ОЧЕНЬ важно иметь возможность сбагрить ребенка бабушкам или хотя бы тётям или в садик
- есть такие родители (лично знаком), которые говорят, что нет-нет, никаких бабушек, они неправильно воспитают, разбалуют, испортят, в общем. И потом мама сидит с чадом до полного и окончательного помутнения
"нет нет никаких бабушек" это ебануто, ты не можешь несколько лет проводить в режиме 24/7 напряжения и спать по 6 часов, нужны выходные и время без ребенка, иначе никак
тогда няня (и сад с некоторого возраста) спасут
Расходимся.