[
If you spend half your time thinking about how to optimize your code, you could be twice as productive simply by stopping to do so. It is very rare that speed is an issue, and in almost all cases you can speed up the bottleneck by changing the underlying way you do it. Which has nothing whatsoever to do with the compiler.
Simple example: if you have a huge dataset that you filter in many places to extract the relevant information, you could speed that up a lot by using multiple, different queries and/or datatsets. And you could speed those up by using stored procs instead. That has a far greater impact on the speed of your application than any compiler optimization.
In short: always ignore speed unless it becomes a problem, at which point you should search for the bottleneck and fix only that.
Yes, I know that is the opposite philosophy of C++, where speed is always the most important consideration.
For me, the most important thing is always the readability.
И да, и нет. Это зависит от разрабатываемых приложений. Если конечный результат программа которой будут только пользоваться, и не для дальнейшей разработки с её помощью, то тут можно просто не задумываясь делать приложение и выдавать результат. Учитывая критичные места.
Но если приложение/библиотека будет использоваться для дальнейшей разработки, то в таком случае "всё должно идти с иголочки" (по возможности). И каждая вызываемая процедура должна быть отработана или в ней должно быть указание, что в ней не отработано и по какой причине.
В противном случае, все недоработки, которые несёт с собой приложение/библиотека - могут создать проблемы для программиста который пользуется данным инструментом. И программисту придётся искать другой путь, другую библиотеку или самому писать заново подобные функции/процедуры. Что означает, что вы просто заставили человека сделать дополнительную работу, хотя он хотел заниматься разработкой основного приложения.
Что по поводу читабельности - это может быть воспринято по разному. Если это относится к форматированию текста и документированию его, то да. Если же это относится к тому, что компьютер должен понимать что пишет человек - то нет! Причём совсем нет!
Если мы пишем программу легко воспринимаемую компьютером, но достаточно непросто воспринимаемую программистом (и совсем не воспринимаемую обычным человеком), то это ближе к развитию и человека и программы для компьютера.
Если же мы пишем программу, которую достаточно просто поймёт обычный человек, но "сломает ногу" машина, для которой мы это писали - то это деградация и программиста и машины. Вы не получите должного результата. И будете дальше надеяться на мощности вашего компьютера, а он будет "тормозить".
Yandex translate:
Yes and no. It depends on the applications being developed. If the end result is a program that will only be used, and not for further development with its help, then you can just make an application without hesitation and give the result. Considering critical locations.
But if the application / library will be used for further development, then in this case "everything should go from scratch" (if possible). And each procedure called must be worked out or it must indicate what has not been worked out in it and for what reason.
Otherwise, all the flaws that the application / library brings with it can create problems for the programmer who uses this tool. And the programmer will have to look for another way, another library, or re-write similar functions/procedures himself. Which means that you just forced the person to do extra work, even though he wanted to develop the main application.
What about readability - it can be perceived in different ways. If this applies to formatting text and documenting it, then yes. If this refers to the fact that the computer must understand what a person is writing, then no! And not at all!
If we write a program that is easily perceived by a computer, but is not easily perceived by a programmer (and not at all perceived by an ordinary person), then this is closer to the development of both a person and a computer program.
If we write a program that an ordinary person will understand quite simply, but the machine for which we wrote it will "break its leg", then this is the degradation of both the programmer and the machine. You will not get the proper result. And you will continue to rely on the power of your computer, and it will "slow down".
-----------------------------------------------------------------------------------
Я протестировал программы (и буду дальше тестировать), посмотрел определённые места компилятора. Оптимизация самого компилятора FPC застопорилась примерно лет 10 назад. Видимо ею ни кто не занимался и все полагаются на ресурсы компьютера. Причём, для Windows компилятор FPC более сильно оптимизирован, чем для Linux (и вероятно для других систем так же - менее оптимизирован). В некоторые моменты поведение компилятора непредсказуемо. Компилятор может выполнить оптимизацию, а в следующий момент не выполняет (допустим, в разных процедурах работая со статическими данными). Я ещё далеко не достаточно глубоко залазил внутрь компилятора и не полностью рассмотрел смотрел что он делает.
В ряде случаев, вы можете отказаться от "String" паскаля и работать с текстом сами. Компилятор зачастую (если вы сами хотите производить какие-то действия с текстом) добавляет код, который несёт дополнительные расходы (это правильно для большинства! Редко, но некоторые люди хотят контролировать сами процесс работы с текстом).
Функция StrToInt устарела (вероятно и StrToFloat тоже, не проверял). Средствами паскаля (даже не ассемблера) её можно ускорить минимум в два раза, если не больше. Функцию IntToStr с помощью паскаля не ускоришь, добавляются накладные расходы на текст, и в данном случае компилятор достаточно неплохо справляется с текстом.
Компилятор FPC уже достаточно давно надо пересматривать в сторону оптимизации. Какие-то части он оптимизирует достаточно неплохо, а какие-то просто игнорируются и рассматриваются обычной последовательностью кода.
yandex translate:
I tested the programs (and will continue to test), looked at certain places of the compiler. Optimization of the FPC compiler itself stalled about 10 years ago. Apparently, no one was engaged in it and everyone relies on computer resources. Moreover, the FPC compiler is more highly optimized for Windows than for Linux (and probably less optimized for other systems as well). At some points, the compiler's behavior is unpredictable. The compiler can perform optimization, and the next moment it does not (for example, working with static data in different procedures). I haven't gone deep enough into the compiler yet and haven't fully considered what it does.
In some cases, you can abandon Pascal's "String" and work with the text yourself. The compiler often (if you want to perform some actions with the text yourself) adds code that incurs additional costs (this is correct for most! Rarely, but some people want to control the process of working with the text themselves).
The StrToInt function is outdated (probably StrToFloat too, I didn't check it). By means of Pascal (not even assembler), it can be accelerated at least twice, if not more. You can't speed up the IntToStr function with pascal, text overhead is added, and in this case the compiler copes with the text quite well.
The FPC compiler has had to be revised in the direction of optimization for a long time. He optimizes some parts quite well, and some are simply ignored and considered by the usual sequence of code.