Just setting the stage here...I am not a 4GL expert but was trying to show our developers how to use background threads in VB.NET to use animated images on forms.
So I created a Progress .NET form with a button and put this code in the click event so that the foreground thread would be busy..to show that animated images need their own thread or that the processing needed to be a separate worker thread from the form.
def variable i as integer init 0. pictPleaseWait:Visible = true. lblStart:Text = STRING(NOW). process events.
do while i < 999999999 :
i = i + 1.
pictPleaseWait:Visible = false. lblEnd:Text = STRING(NOW). RETURN.
Now here is the code on my vb.net form with code behind on click event.
Dim i As Integer = 0 lblStart.Text = Now.ToLongTimeString
pictPleaseWait.Visible = True
Do While i < 999999999
i = i + 1
pictPleaseWait.Visible = False lblEnd.Text = Now.ToLongTimeString
The progress code takes minutes to run...the vb code takes seconds....
Any idea why?
The Core Client team is committed to supporting and enhancing the ABL, which includes improving the performance of the language.
The team has discussed the use of LLVM several times in the past and although we have not moved forward with a project which leverages this technology we are not opposed to integrating newer technologies into the product. However, each project needs to be evaluated against the other projects which PM identifies as a priority for a release.
From time to time an example is posted to Community which highlights the performance other languages vs. the ABL. We will continue to review these situations and if we determine there is a real benefit to the ABL we will investigate optimizing the Language.
We have investigated and are continuing to analyze our OOABL infrastructure, looking for optimizations we can make. When optimizations can be safely made, we implement these changes.
The point of this thread is to identify that runtime performance is important and in that, there is agreement. Working with PM, this development effort must be prioritized with the team’s other development tasks.
Sr. Development Manager
Sorry that this has turned into two completely unrelated conversations. But re post above by swilson-musco:
Process-events is in the trigger to allow the main form to enable the .NET picture box with an animated gif.
I thought you said the animation was happening in another thread. So why do you need to be processing events on this main UI thread to make it work? Besides, you were JUST in a WAIT-FOR, processing events, before this trigger code ran.
I still don't get why progress completely ignores the ABL performance.
Having a runtime language without JIT or any kind of optimization in 2017 is just madness.
This case just proves that they don't even target the "easy" optimizations.
This is because every time this kind of questions pop up some says that once you hit the database that will be much slower anyway, therefor concluding that the 4GL performance doesn't matter. For what it's worth, I strongly disagree with this...
Architect of the SmartComponent Library and WinKit
> Having a runtime language without JIT or any kind of optimization in 2017 is just madness.
> Me to. ABL performance matters!!!!!!!!!!!
Which kinds of optimizations would give the best value for the investment in time and money?
Is there any quick way of adding JIT, which would fit within the company's available resources, and would remain portable to all platforms?
Oh, and btw, ABL performance is important as well because when it performs good it gives more bang for your bucks on the server. In OpenEdge it is highly beneficial to have your appserver next to the database (shared mem), and the more efficient the ABL is, the more I can run on the the same server before I have to scale out/up.
Every optimization would matter, this has to be a continuous process.
I guess the best (but completely unrealistic) case would be if the port the ABL to something like LLVM.
But yeah...i have no hope that any singificant things will change here.
moving the ABL to llvm would be a huge task.
much of the code is in the runtime anyway.
that said, there are quite a few worthwhile performance improvements that could be made to the 4GL interpreter.
as with any other improvement, what gets done or not done is all a matter of priorities.
go to the PUG Challenge in Manchester NH tomorrow. Pester Evan.
I sometimes wonder why PSC does little compiler ptimizations. Is it because it's to risky?
> This case just proves that they don't even target the "easy" optimizations.
I don't think so.Time of DO loop on the same box per Progress version:
8,610 7.3C (VM)
> On Jun 3, 2017, at 5:42 PM, onnodehaan wrote:
> I sometimes wonder why PSC does little optimizations. Is it because it's to risky?
it is a question of on what are the most important things to spend the finite developer time.
go to the PUG Challenge and pester Evan Bleicher.
I appreciate the answers given..my intent was not to ruffle any feathers..just trying to learn and understand. As stated earlier, I am not a 4GL expert. My job is more of a DBA/Architect role and when developers come to me as say "Doing X or Y is slow" generally the first reaction is we need more hardware or faster storage. Just trying to understand that perhaps the solution isn't to spend more money or build a better mouse trap but consider other language alternatives to get the job done without having to invest a new system design. The Progress DB supports many ways to get to the database, making sure developers are aware of the strengths and weakness of 4GL may influence them on which language will help them get the task done in the least amount of time.
Thank you for your time.
I think that OpenEdge has many good features but the language itself is too slow.I raised often the same problem, objects are slow, simple I = I + 1 and string concatenation is a catastrophe.
I am working in a mixed team, my colleagues are using C# and they are using the cpu power, I can't.ABL GUI is useful for displaying data, some calculation but the rest has to be done on the appserver.If you need hardware support you are forced to write assemblies in C# because they are using multi-threading.
Years ago, as I used OEA the first time (10.2A in Paris), I can't get Mikes presentation out of my head where he was so happy that OE has now a possibility to resize windows and a useful flow control, I head the first contact with the bridge.10.2A was very painful and with 10.2B it made sense to use it.
During this time I joined a German PUG meeting and a member company presented a fully new developed solution based on ABL.NET.
I had the chance to join one year later the next meeting again and we got the same presentation, only with the latest output after one year developing time.
But what happend?!
I noticed that they buried ABL in the frontend and switched to C#, only the background was still using the "big ABL experience", that was the main point for the frontend last year too.I asked them what happened and I was told: They realized that a modern concept wasn't possible because the UI was too slow and had limitations.
If nothing will change it looks like that ABL UI could be a dead end in this kind of implementation.
It's nice to have the ability to use the same code from lightyears ago, this was still the killer argument.But meanwhile UI changed in windows to WPF, none of my colleagues is using winforms anymore.I don't think that WPF will be introduced in ABL, but perhaps it will be buried too like Silverlight and HTML5 and winforms are still there?
I think that Progress could make a hard break to something new without 100% compatibility with old code.Make something new with a new compiler.
Another option could be something like integrating OE into MS VisualStudio and provide a good and easy data and appserver access. Deliver an entity framework OE database provider and a ABL compatibility class like MS did with the first VB.NET version to help users to convert old VB6 code into the new world of .NETThen we could switch to C# with all language components.
It could be that I wrote nonsense but when I understood Mikes comment correct, the client is only fast with data when using datasets and temp-table.
My colleagues do not use this technology anymore since entity frameworks are available.It's not perfect but objects are much better in the UI and compatible to every control and with ABL a performance nightmare.
My 2 cents.
I tried a development tool to write a program in "VB6 like" syntax and run it in its IDE using JAVA 8 JDK. If this development approach can be applied to ABL, I can use ABL to write programs and make use of JAVA runtime.