Page 11 of 16

Posted: Mon Oct 10, 2005 4:57 pm
by Ralf
for Wolf: We are talking about PureBasic and not about other Basic lanugages :wink:

for Fred: Sure, 2,5 kb isnt bad but when it could be smaller. Using 10 kb for a window and EventLoop could be a lot smaller in size! FASMCam is a very nice and extrem small FASM example opening a window with buttons and getting access to your webcam. The example and source are free and the exe is only 3072 bytes! :wink: http://flatassembler.net/examples.php

Posted: Mon Oct 10, 2005 5:01 pm
by Polo
Fred wrote:It's already the case. 2,5 kb for a small executable isn't bad at all, you're getting really picky. If you look closely to the generated code, there isn't a lot of garbage or unuseful stuffs. For OpenWindow(), there is the event loop in it and some routine to manage the objects. Well, opening a window alone isn't that useful, right ?
Sorry Fred, I agree with Ralf.
You know, "good things" make people want "even better things" :wink:
Because you created a so good language, you made us all really exigeant, entirely your fault :lol: :lol: :wink:

Posted: Mon Oct 10, 2005 5:07 pm
by Psychophanta
Polo wrote:Because you created a so good language, you made us all really exigeant, entirely your fault :lol: :lol: :wink:
Yes, you have hitted in the point 8)
Perhaps Ralf is overpassing exigences comparing entire ASM programed apps with PB ones. Mmmm ... I said "Perhaps" :D

Posted: Mon Oct 10, 2005 5:20 pm
by va!n
@Polo and Psychophanta:
8) :)

@Ralf:
3,5 KB only for a window with buttons and webcam access? WOW! :shock: very impressing but please note that purebasic isnt to compare with 100% written ASM applications! Perhaps i have to agree in some points and there could be some more optimizing (speed/size) potential for PureBasic!? However let us wait for v4.0! Fred is doing a nice job! :wink:

Posted: Mon Oct 10, 2005 7:33 pm
by va!n
i have read Ralf´s posting and have experienced a bit with the compiled exe size and included stuff! I have spend some hours today to get a smaller filesize with purebasic and now i am back with possible a new worldrecord in purebasic :lol:

i have wrote a very small and simple example, showing only a MessageRequester (using API) printing "test" as title and same for the message text!

here are my results:

2560 bytes - original created by PB, unpacked!
2560 bytes - original created by PB, unpacked, exe modified !!
1305 bytes - original created by PB, packed! (Win32 exe, no *.com nor cab file!)
918 bytes - original created by PB, exe modified, packed (pure Win32 exe, no *.com nor cab file!))

918 bytes - i think this is the smallest "packed" PureBasic exe program ever made with a normal Win32 header (no *.com nor cab patch!) !? :D The third and fourth file are packed with the same packer and the same pack options! So the size different only happens because of "some dirty file modifications" !!! (see it as a small and dirty hack!) :wink:

You can download the example files to see that its not a fake, just only a hack :lol: - i did it just for fun!

download here

Edit:
I know the "2560 bytes - original created by PB, unpacked, exe modified" version could be reduced to 2048 bytes! (but not implented in this test) ;-P

Posted: Mon Oct 10, 2005 11:03 pm
by Tranquil
What is the intention of this thread? Compiling PB exes down to 2kb in 4.0?

In times of 1 GB available memory it realy doesn't matter if an exe is 1MB oder 1.2 MB.

Silly discussion, Back to main topic....

Posted: Mon Oct 10, 2005 11:07 pm
by Psychophanta
Tranquil wrote:In times of 1 GB available memory it realy doesn't matter if an exe is 1MB oder 1.2 MB.
Tranquil, if you develop a compiler, I wouldn't use neither purchase it :!:
Never mind times of 1GB or times of 10^100 TB. This is nothing to do with that. This have to do with optimization of a compiler (called PB) :wink:

Posted: Mon Oct 10, 2005 11:12 pm
by Tranquil
Take a look on other compiler such as those from M$ and take a look on what the hell their include in their exe. and it sells better then sex. So...

EDIT: I will never code a compiler couse there is no need to invent the weel a second time. :)

Posted: Mon Oct 10, 2005 11:14 pm
by Psychophanta
Not always quality=sales.

Posted: Mon Oct 10, 2005 11:19 pm
by Tranquil
I think it is realy difficult in huge projects to see all the lags. Its absolutly normal. More code means more unnessesary code and more bugs. But this is not only a PB thingie thats a problem in all sourcecodes on all plattforms.

Before optimizeing bughunting is the mostly needed part of developing pb.
and this should be the direction for furthure versions of PB, to come back to the inital topic.

- Go away fom String-Buffers to enable strings-savety use in threads
- logs/ quadlongs etc. for beeing compatible with database works

The last release of PB was a very improtend one if I take a look on the new debuggers. But indeed, there is realy A LOT to do for PB.

Posted: Mon Oct 10, 2005 11:34 pm
by Psychophanta
Yes, of course, there are a lot of things, but must be done taking care :)

Posted: Mon Oct 10, 2005 11:34 pm
by Fred
Ralf: you just don't get it. The OpenWindow() does more than doing some API calls (Queued resize event, several flags to align the window, managing shortcuts etc.). What don't you use full API in PB ? You should get similar size. About the lowest executable footprint, i done a code review and removed 1 kb. It won't change the face of the world, but for v4, a MessageBox_() program will be 1,5 kb.

Posted: Tue Oct 11, 2005 12:04 am
by va!n
Fred wrote:About the lowest executable footprint, i done a code review and removed 1 kb. It won't change the face of the world, but for v4, a MessageBox_() program will be 1,5 kb.
@Fred:
Wow! :shock: Thats very impressing! You have beat me! :wink: Keep on your great work!

Posted: Tue Oct 11, 2005 4:39 pm
by Polo
1kb less, sorry, but it's something :) It means that there was 1000 of not useful things in the exe, so you haven't wasted your time, Fred ;)

BTW, it's not because you have more and more gigs that you HAVE to use it ! I personnally think that you always try to do the smaller as possible, because most of the time (not always, but mostly), smaller = faster.
Leave your disk space and memory for other things likes media, because it's them which should takes the more place (coz for media, bigger = better quality, unlike apps)

Posted: Tue Oct 11, 2005 4:50 pm
by KameHameHaaa
Fred should work in more critical (and useful) issues instead of optimizing things already well done... IMHO

I would prefer faster than smaller too. (in-line procedures, un-rolled loops etc.)