Delphi 11.3 is available now!

[Gary 17]

11.3 on my laptop 13" Project menu doesn't fit on screen and cannot scroll so Project/Options (Last Item) and Eurekalog options are inaccessible. Anyone else have this problem?

[programmerdelphi2k 235]

Quote

• DirectX 11 capable video card that runs at 1440x900; a 1080 vertical resolution screen is recommended.

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Installation_Notes

[David Heffernan 2296]

11 hours ago, Erix A. said:

What's your point?

Frustration at my dev tool lagging behind. The editor is the least of my worries. It's the poor and never changing performance of the code emitted by the compiler that frustrates me the most. 

[Vandrovnik 202]

11 hours ago, Gary said:

11.3 on my laptop 13" Project menu doesn't fit on screen and cannot scroll so Project/Options (Last Item) and Eurekalog options are inaccessible. Anyone else have this problem?

You can still use Ctrl+Shift+F11 or Alt+p, o.

[Lars Fosdal 1731]

The What's New presentation made a point of the number of issues that were fixed for 11.x versions - nearly 3k of them.

The amount of issues highlights the need for a change in their development process. 

 

The marketing driven release process needs to come to an end, and a quality driven release process to replace it. There are many good developers in the team, but there is not enough time/resource to ensure that quality is the primary goal. There also seems to be developers that write code that really is sub par, but no process that corrects it. Instead, it seems to be, "let's add this cool new feature for the sales guys and release it on this pre-determined date to make sure marketing can maximize their campaigns".

 

That needs to change.

[A.M. Hoornweg 138]

2 hours ago, David Heffernan said:

Frustration at my dev tool lagging behind. The editor is the least of my worries. It's the poor and never changing performance of the code emitted by the compiler that frustrates me the most. 

I suppose that would make 11.3 binary incompatible to existing packages.  

 

Can serious optimization be done by a single pass compiler anyway?

[Patrick PREMARTIN 50]

1 hour ago, Lars Fosdal said:

The What's New presentation made a point of the number of issues that were fixed for 11.x versions - nearly 3k of them.

The amount of issues highlights the need for a change in their development process. 

 

here is a screen capture of the presentation with numbers

 

 

the product is big, many different usage are done with it, I can understand bugs are there. we can discuss the delay for fix to be delivered, but about the amount of requests I'm not sure they can do anything (even if some bugs should not passed alpha and beta releases, but beta testers (like me) can't check everything except projects we work on).

[Patrick PREMARTIN 50]

25 minutes ago, A.M. Hoornweg said:

I suppose that would make 11.3 binary incompatible to existing packages.  

 

11.3 DCU are compatible with 11.x DCU branch (except some for C++Builder before 11.1.5 as I remember)

[David Champion 46]

2 hours ago, A.M. Hoornweg said:

Can serious optimization be done by a single pass compiler anyway?

Don't believe Delphi is a single pass compiler. If someone who knows more please comment.. 

 

edit: this Embarcadero blog suggests that it is single pass 

Edited March 3, 2023 by David Champion
correction

[David Heffernan 2296]

1 hour ago, A.M. Hoornweg said:

I suppose that would make 11.3 binary incompatible to existing packages.  

 

Can serious optimization be done by a single pass compiler anyway?

Binary compatibility for packages isn't something that bothers me. I mean, you get a major new upgrade and that happens anyway. But better code gen wouldn't mean changes to binary compatibility for packages. Also is 11.3 even binary compatible with 11.2 packages?

 

Why do I want a single pass compiler? I'm not the end user. I want to deliver a program that runs quickly. Am I going to tell my customers, I don't want to deliver a program that runs twice as fast because then I wouldn't have a single pass compiler. Why do my customers care about single pass compilers? Is that something that your users talk to you about?

[A.M. Hoornweg 138]

2 minutes ago, David Heffernan said:

Binary compatibility for packages isn't something that bothers me. I mean, you get a major new upgrade and that happens anyway. But better code gen wouldn't mean changes to binary compatibility for packages. Also is 11.3 even binary compatible with 11.2 packages?

 

Why do I want a single pass compiler? I'm not the end user. I want to deliver a program that runs quickly. Am I going to tell my customers, I don't want to deliver a program that runs twice as fast because then I wouldn't have a single pass compiler. Why do my customers care about single pass compilers? Is that something that your users talk to you about?

 

I did not need to recompile my third-party 11.2 packages (TMS Components, LMD Components, Intraweb), so I guess 11.3 is binary compatible to 11.2.

 

 

I certainly wouldn't mind having a thorough 2-pass compiler producing fast and tight executables for release mode.   But during development and debugging I prefer F9 to be fast.

 

 

[Uwe Raabe 1881]

20 minutes ago, David Heffernan said:

Also is 11.3 even binary compatible with 11.2 packages?

It is indeed. That is also the reason why a couple of bugs are fixed and features implemented the way they are or not even at all.

[dummzeuch 1390]

1 hour ago, David Heffernan said:

Why do my customers care about single pass compilers? Is that something that your users talk to you about?

They may not care about the technicalities, but they do care about the time it takes to develop the software, and that depends a lot on turnaround times. And all else being equal(*1), a single-pass compiler is inherently faster than a multi-pass compiler.

 

(*1: Of course, a badly written single-pass compiler could still be slower than a well-written multi-pass compiler).

[Lars Fosdal 1731]

Personally, I'd sacrifice build speed over code speed, and there are ways to reduce the impacts of slower build speeds, like continous background builds, etc.

[SwiftExpat 65]

3 hours ago, Patrick PREMARTIN said:

but beta testers (like me) can't check everything except projects we work on

Agreed.

5 hours ago, Lars Fosdal said:

There also seems to be developers that write code that really is sub par, but no process that corrects it.

That process is QP defects, but it is too late in the game. That is not fair to the developer (and should be planned for).

 

As a beta tester I am testing with only a small time allocation, 1-2 hours per week. From my point of view, some focus to the beta cycle should be added to get the most out of beta testers. Establish coverage by dividing up focus groups by feature:

• Allow me to choose 2-5 features I use in the IDE
• Assign 1-2 features I use rarely but am familiar with

[Brian Evans 83]

Performance wise there is some outright bad codegen and basic features that could be done without too much work (the proverbial low hanging fruit) in Delphi. As the decades go by and other environments push the state of the art staying so far behind the pack is getting more and more a negative. Would be nice to see some improvements in this area. Adding some optional passes for codegen optimization would help a lot - easy to bypass if there are problems or faster compilation is desired. 

 

 

[David Heffernan 2296]

3 hours ago, dummzeuch said:

They may not care about the technicalities, but they do care about the time it takes to develop the software, and that depends a lot on turnaround times. And all else being equal(*1), a single-pass compiler is inherently faster than a multi-pass compiler.

 

(*1: Of course, a badly written single-pass compiler could still be slower than a well-written multi-pass compiler).

It's entirely possible to have a compiler that is fast during development / debug builds, but takes more time to optimise for release builds. So much Stockholm Syndrome in Delphi-land!

[Brandon Staggs 185]

10 hours ago, David Heffernan said:

Frustration at my dev tool lagging behind. The editor is the least of my worries. It's the poor and never changing performance of the code emitted by the compiler that frustrates me the most. 

As for the compiler, I am more interested in Embarcadero moving away from compilers they maintain to an open architecture that doesn't depend on Embarcadero developers for improvement at all. But I do not agree that code efficiency is the primary issue. Faster binaries are great. But an IDE that doesn't choke on its own syntax is far more important to me. Editing features that are taken for granted in other IDEs and text editors getting implemented in Delphi impact my daily work far more than a few unused x64 registers.

[David Heffernan 2296]

13 minutes ago, Brandon Staggs said:

As for the compiler, I am more interested in Embarcadero moving away from compilers they maintain to an open architecture that doesn't depend on Embarcadero developers for improvement at all. But I do not agree that code efficiency is the primary issue. Faster binaries are great. But an IDE that doesn't choke on its own syntax is far more important to me. Editing features that are taken for granted in other IDEs and text editors getting implemented in Delphi impact my daily work far more than a few unused x64 registers.

I don't see why there should be compromise. I want great tools and efficient code output.

[dummzeuch 1390]

3 hours ago, David Heffernan said:

It's entirely possible to have a compiler that is fast during development / debug builds, but takes more time to optimise for release builds. So much Stockholm Syndrome in Delphi-land!

You are interpreting interesting things into what I wrote. But you and I have a history of talking at cross purposes (that's DeepL's translation of "aneinander vorbeireden") with each other, so I was expecting something like this.

[David Heffernan 2296]

3 hours ago, dummzeuch said:

You are interpreting interesting things into what I wrote. But you and I have a history of talking at cross purposes (that's DeepL's translation of "aneinander vorbeireden") with each other, so I was expecting something like this.

I don't really see that this is so. Don't you want fast compilation and fast executable code? I'm sure you do. Do you think that you can have one but not the other? 

[Die Holländer 20]

I just went from D10.4 to D11.3 and this was the smoothest installation I've experienced.

Installing about 30 extra components (with source 😉) on a huge code base and some components

installed with use of GetIt. Nice that source and design can be separate screens again.

I also experienced that the IDE is much more responsive and quick. Also tested code compiled

to Linux running on Docker with Ubuntu and the PAServer. Just great. Thanks.

 

 

[rgdawson 7]

Been working with 11.3 since it came out.  Very smooth upgrade from 11.2.

 

My other observations are:

 

As before, using inline variables seems to break certain code refactoring functions like Rename Variable, which I like to use more than I like inline variables, so I don't use inline variables.

 

The new editor feature that highlights words that you select where visible elsewhere in the editor causes the editor to scroll unexpectedly if you are using folding, which I do, so I had to disable that feature.

 

LSP does not seem to fail anymore.

 

Control-Click jumps in the editor don't stop working near as often as before, but still do sometimes.  In that case I use Ctrl-G or I reboot the IDE.

 

The compiler is fast as blazes as far as I am concerned.  When I was young, I learned guitar by practicing during compiles, haha.  Nowadays compiling 100,000 lines of code takes only a few seconds.

 

I just frickin' love Delphi.  I am very happy it exists.

[programmerdelphi2k 235]

LSP still stopping yet... just look in "window messages (on bottom screen)" you can see the message: LSP stopped... restarting

Edited March 21, 2023 by programmerdelphi2k

[David Heffernan 2296]

5 hours ago, rgdawson said:

The compiler is fast as blazes as far as I am concerned. 

Not the 64 bit windows compiler