I've followed the revival of MIDlet Pascal closely as I've enjoyed the superb yet buggy version v2.2…
1. One issue that I've noticed (also present in v3 I think) is that multi-dimensioned arrays seem to take too much memory. For example, an array of may hang the application but a one dimensioned one of won't. I've now stopped using multi-dimensioned arrays as even a few small ones cause the compiled app to crash.
2. Loading a v2.2 mpsrc file into v3 puts a blank line between each line of code -
3. Support for arrays within record types would be very useful.
4. The only other thing is the painful compile times in v3 (40 minutes on a Core 2 Duo system for a 730 line program) - I'm aware the compiler is being re-written. I've returned to v2.2 for now.
I'm excited that the project is ongoing and look forward to later versions!
Sincere thanks,
Professor Yaffle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
40 minutes?! Well, I test on a Core 2 Duo too, and a 2,500 lines program takes only a minute to build.
How many resources do you have in the project? If you have hundreds of resource files it may take several minutes due to the way the resource files are being added to the JAR file, a problem that I'm already aware as posted in other thread and will try to solve.
Thanks for your comments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tested the 'Tetris' code from the MP2.02 site - roughly 680 lines including empty lines for readability - on my single core Althlon 3200+. It took only a few seconds, so Javier and I don't seem to have problems. I'm running XP with 2G of RAM.
There could be something strange about your code that is exposing a problem in the compiler. Could you send me a copy?
midletp at lvcott dot fsnet dot co dot uk
Thanks for the comments - I'll try multi dimension arrays in one of the test files for the new compiler, and see if that gives any clues about problems in the current compiler.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To help develop the pascal version of the compiler, I'm using various partial builds of the same basic version of the C compiler used in V3 Beta, but built with M$oft Visual Studio 2008 C++ Express (the free version). A release build (ie no debug) of the full compiler gives me a 310K .exe.
On my system (AMD 3200+ single core, 2G RAM, 400G IDE HD) a build of this source takes around 8 minutes using the M$ compiler build, but with V3 Beta 2 it takes 95 minutes to produce the class file (90 minutes to compile, 5 minutes to preverify), and 20 minutes later I was still waiting for it to end, so I killed it :(
So something is obviously a bit wrong!! I'm sorry I said the compile time was 'an inconvenience' but until your post I hadn't realised it was so long.
best wishes ..wes
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Top stuff - hopefully my odd code has at least instigated a speedier compiler and I'm sure the guys will get to the bottom of what exactly in my code the compiler is getting tied up in knots with! If I stumble across anything whilst testing, I'll let you know.
Many thanks,
Professor Yaffle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally, today I had time to search for the problem causing this totally insane compilation time.
The problem is related with big records, with many fields I mean (if you want, build up a project with a record with 40 fields and write some code that access them, lets say 10 times each field, and take a seat).
Whats going on? Well, first of all, records in MP are converted into classes (those R_<number>.class you may find).
When you access a field of a record (to get or set a value), the compiler will look into the information of that record type to see what field you are trying to access and will generate the right code to access that field.
That information read, search and manipulation is performed against binary trees, string lists, etc, and with string comparisons that involves thousands of memory allocations, reallocations and releases, which are slower than usual in this case since they are been hooked by the external memory handler (the reason for that its mostly explained in old ALPHA readmes), which had not give us headhaches until now.
So, a temporary workaround to deal with this is (if you want to try): close MP, rename the mp3CCMH.dll file that you will find the installation directory to something else and restart MP. With this, MP wont find any external memory handler, and the compiler may work faster (but sometimes may fail to compile too… anyway, the IDE will try to compile up to 3 times if it fails).
This may get you better compilation times by the moment. But if you want to dramatically speed up the compilation time in this BETA 2, you can reduce the size of your big records and minimize the access to its fields.
Btw, if you use array of records, be sure to not initialize records directly in code (this will be time consuming in compilation-time and also in run-time), instead of that use a for loop and fill the fields reading a resource file you can fill by hand with the desired data previously. And do that read process in the initialization of a unit, to get your information loaded at startup.
All this hints are also a more cleaner way to write your code (check the demos included in BETA 2).
Resuming, this all means the BETA period will be longer than I had planned, since I have to think what to do, implement it in both sides (IDE and Compiler), test it, and after that release a new BETA version so the whole community can test it too… and my free time is very short lately as I told in the readmes (im working in so many projects at the same time), so lets see what happens.
Thanks to both for the report and the tests!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Excellent feedback and encouraging. I was planning to add further resource files to reduce in-code record initialization, so will see how this improves things. Will also rethink use of records in some instances.
Keep up the good work!
Professor Yaffle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've followed the revival of MIDlet Pascal closely as I've enjoyed the superb yet buggy version v2.2…
1. One issue that I've noticed (also present in v3 I think) is that multi-dimensioned arrays seem to take too much memory. For example, an array of may hang the application but a one dimensioned one of won't. I've now stopped using multi-dimensioned arrays as even a few small ones cause the compiled app to crash.
2. Loading a v2.2 mpsrc file into v3 puts a blank line between each line of code -
3. Support for arrays within record types would be very useful.
4. The only other thing is the painful compile times in v3 (40 minutes on a Core 2 Duo system for a 730 line program) - I'm aware the compiler is being re-written. I've returned to v2.2 for now.
I'm excited that the project is ongoing and look forward to later versions!
Sincere thanks,
Professor Yaffle
40 minutes?! Well, I test on a Core 2 Duo too, and a 2,500 lines program takes only a minute to build.
How many resources do you have in the project? If you have hundreds of resource files it may take several minutes due to the way the resource files are being added to the JAR file, a problem that I'm already aware as posted in other thread and will try to solve.
Thanks for your comments.
I tested the 'Tetris' code from the MP2.02 site - roughly 680 lines including empty lines for readability - on my single core Althlon 3200+. It took only a few seconds, so Javier and I don't seem to have problems. I'm running XP with 2G of RAM.
There could be something strange about your code that is exposing a problem in the compiler. Could you send me a copy?
midletp at lvcott dot fsnet dot co dot uk
Thanks for the comments - I'll try multi dimension arrays in one of the test files for the new compiler, and see if that gives any clues about problems in the current compiler.
Thanks both for the prompt replies - I've emailed my source to Wes as requested.
I've used 4 modest resource files and even excluding these makes no difference to the 40 minute compile time (in v3 Beta 2 also).
Looking forward to developments as I think MP has a real future!
Many thanks,
Professor Yaffle
Thanks Prof. Code received.
To help develop the pascal version of the compiler, I'm using various partial builds of the same basic version of the C compiler used in V3 Beta, but built with M$oft Visual Studio 2008 C++ Express (the free version). A release build (ie no debug) of the full compiler gives me a 310K .exe.
On my system (AMD 3200+ single core, 2G RAM, 400G IDE HD) a build of this source takes around 8 minutes using the M$ compiler build, but with V3 Beta 2 it takes 95 minutes to produce the class file (90 minutes to compile, 5 minutes to preverify), and 20 minutes later I was still waiting for it to end, so I killed it :(
So something is obviously a bit wrong!! I'm sorry I said the compile time was 'an inconvenience' but until your post I hadn't realised it was so long.
best wishes ..wes
Thanks, Wes.
Top stuff - hopefully my odd code has at least instigated a speedier compiler and I'm sure the guys will get to the bottom of what exactly in my code the compiler is getting tied up in knots with! If I stumble across anything whilst testing, I'll let you know.
Many thanks,
Professor Yaffle
Finally, today I had time to search for the problem causing this totally insane compilation time.
The problem is related with big records, with many fields I mean (if you want, build up a project with a record with 40 fields and write some code that access them, lets say 10 times each field, and take a seat).
Whats going on? Well, first of all, records in MP are converted into classes (those R_<number>.class you may find).
When you access a field of a record (to get or set a value), the compiler will look into the information of that record type to see what field you are trying to access and will generate the right code to access that field.
That information read, search and manipulation is performed against binary trees, string lists, etc, and with string comparisons that involves thousands of memory allocations, reallocations and releases, which are slower than usual in this case since they are been hooked by the external memory handler (the reason for that its mostly explained in old ALPHA readmes), which had not give us headhaches until now.
So, a temporary workaround to deal with this is (if you want to try): close MP, rename the mp3CCMH.dll file that you will find the installation directory to something else and restart MP. With this, MP wont find any external memory handler, and the compiler may work faster (but sometimes may fail to compile too… anyway, the IDE will try to compile up to 3 times if it fails).
This may get you better compilation times by the moment. But if you want to dramatically speed up the compilation time in this BETA 2, you can reduce the size of your big records and minimize the access to its fields.
Btw, if you use array of records, be sure to not initialize records directly in code (this will be time consuming in compilation-time and also in run-time), instead of that use a for loop and fill the fields reading a resource file you can fill by hand with the desired data previously. And do that read process in the initialization of a unit, to get your information loaded at startup.
All this hints are also a more cleaner way to write your code (check the demos included in BETA 2).
Resuming, this all means the BETA period will be longer than I had planned, since I have to think what to do, implement it in both sides (IDE and Compiler), test it, and after that release a new BETA version so the whole community can test it too… and my free time is very short lately as I told in the readmes (im working in so many projects at the same time), so lets see what happens.
Thanks to both for the report and the tests!
Excellent feedback and encouraging. I was planning to add further resource files to reduce in-code record initialization, so will see how this improves things. Will also rethink use of records in some instances.
Keep up the good work!
Professor Yaffle