Pelles C forum
Pelles C => Bug reports => Topic started by: pkedpker on April 24, 2014, 06:44:14 AM
-
My Pelles C for Windows 7.00.355 IDE freezes up completely into white screen until it finishes saving takes about 10 seconds to save 22354 lines in main.c file.
The same file also with syntax highlighting in EditPadPro is instant saving changes all over the file. So yeah you can fix it up it's less then a bug I guess more of a need for optimization.
-
What kind of system you have ?
What size / kind of file that main.c is ?
-
757 KB (775,394 bytes)
Windows XP SP3
Always takes 10 seconds to save any change.
Now I edit the files in EditPadPro and wait for the
The file 'main.c' has been changed outside the editor. Do you want to reload it?
Thats how I make changes now it, it's not too bad haha but the IDE is useless.. not to mention missing support for word wrapping so I don't have to use the bottom scroll bar for very long files but I understand thats so the line numbers match up for debugging errors or something but still doesn't feel smooth enough.
Here is a video of the process I made it's a 1 minute video the file is 6 Megs.. divx/avi format, compressed in RAR format.
http://www.mediafire.com/download/xth72wq2wm1tq3q/2014_04_24_06_48_23_984x900.rar
-
757 KB (775,394 bytes)
Thats how I make changes now it, it's not too bad haha but the IDE is useless.
I'm sure most coders would think having a file that large is silly, why don't you split it?
I tried a 630k file and it saved fine, 1.3m and it took 10secs.
John
-
Makes no sense EditPadPro takes a millisecond to save no problem why not do the same with Pelles.. I guess it works by saving offset what was changed like patching a file in hex-editors.. if no massive changes something simple like that.
I'm trying to keep the project in 1 single file. That's why I use C to avoid classes. just structures and pointers haha.
-
I'm sure most coders would think having a file that large is silly, why don't you split it?
Imagine you have a problem with the variable g_hwndMain. You know it has been defined somewhere in a source or header file. How much time will you waste finding the error, if your project is spread over twenty little *.c and *.h files?
I checked how long it takes to save one MB from a RichEdit control: less than 100ms. So there is clearly a little problem there. The same file saved from POIDE takes less than one second, so it seems POIDE is not the culprit.
-
I'm sure most coders would think having a file that large is silly, why don't you split it?
Imagine you have a problem with the variable g_hwndMain. You know it has been defined somewhere in a source or header file. How much time will you waste finding the error, if your project is spread over twenty little *.c and *.h files?
Generally people with little experience in C put all their code in one file. To have such an unwieldy file is not a sensible. Using the IDE's facilities means almost no time is wasted.
John
-
I prefer to have many small files with well defined scope, so when I have a problem in a specific area of work I could open the file containing routines for these actions.
Anyway someone could have different preferences.
But the point here IMO is related to backup and safety options used in the IDE. Synch with OS events for saving restoring and file modifications (the IDE is aware of external file accesses).
The editor should not be a simple RichEdit control, but a custom control with expanded functionalities.
If you are more confortable with another editor I don't think there is any problem in using it... ;)
-
Using the IDE's facilities means almost no time is wasted.
So if my global variable g_hwndMain is spread over, say, three source modules and one header file, which of the IDE's facilities will allow me to see at one glance where it could cause problems?
-
If you think it's better to have large source - go right ahead.
John
-
If you think it's better to have large source - go right ahead.
John
I think it's better to be cautious with expressions like "silly" or "people with little experience".
-
If you think it's better to have large source - go right ahead.
John
I think it's better to be cautious with expressions like "silly" or "people with little experience".
I expressed my opinion and shall do so in future. If you find the words 'silly' and 'little experience' a problem, that's fine.
John
John
-
Makes no sense EditPadPro takes a millisecond to save no problem why not do the same with Pelles.. I guess it works by saving offset what was changed like patching a file in hex-editors.. if no massive changes something simple like that.
Well, the largest file in the largest project that I use with Pelle's C has 3552 lines of code right now (part of the Brandy BASIC interpreter) and it saves in an instant...
I'm trying to keep the project in 1 single file. That's why I use C to avoid classes. just structures and pointers haha.
Well, if you insist on ignoring all good programming practices, then you deserve to be on your own.
And structuring source code into multiple source files has nothing to do with classes, it is good practice in C as well, for the +30 years that I now program in C.
Somehow I think you need to reconsider your programming knowledge/methodology as a whole. With statements like those above, you can only improve/benefit...
Ralf
-
gcc optimization freeks use big C-files and use term for that 'amalgamation'.
look here (https://www.sqlite.org/amalgamation.html) (5 MB).
when working with libraries, separated source-files are must in PellesC.
-
gcc optimization freeks use big C-files and use term for that 'amalgamation'.
look here (https://www.sqlite.org/amalgamation.html) (5 MB).
There are some good arguments to split big sources into smaller modules:
- load and save times are faster
- modern IDEs can effectively handle multiple sources
- modules can be reused in other projects
- modules can be assigned to different team members
That is why splitting is being taught as "good practice".
"Real practice", however, is that:
- load and save times are completely irrelevant with modern hardware, especially for the tiny "modules" that get posted in forums
- some IDEs can't even perform simple searches across sources
- modules are so specific that they'll never be reused in other projects
- modules can't be assigned to different team members because there is only one coder.
Take, for example, the SqLite project. Imagine some Linux user found out that under certain conditions that are difficult to reproduce the output is, ehm, inverted. You guess that there is somewhere a problem with the endianness.
Your codebase consists of 96 C sources. Load it into POIDE and try to find the bug.
Or, alternatively, load the complete C source into an editor that offers you a listbox with all the 73 matches for the term "endian" spread over 147,015 lines of code, as shown below.
Guess which strategy is better to find the bug...
(http://www.webalice.it/jj2006/pics/SqLiteEndian.png)
-
gcc optimization freeks use big C-files and use term for that 'amalgamation'.
look here (https://www.sqlite.org/amalgamation.html) (5 MB).
sqlite is pretty much the only such example that I know off, and they offer that simply due to the fact to eliminate make file problems with all the different target environments. The "optimization" effect I think is much rather secondary here and might likewise depend on the compiler environment being used.
Typical case of "pick your poison".
But for actual development purposes, they also refer to the (96) separated .c and .h files.
Ralf