Newsgroup: it.comp.lang.delphi
Titolo: Dimensioni disumane

Perchè i programmi che scrivo con delphi non occupano mai meno di 170 Kb?
C'è un modo di arrestare la voracità di Delphi?
Grazie!

C'è un modo di arrestare la voracità di Delphi?
In che senso?Per il file exe troppo grande?
Posso chiederti xche, per te, questa cosa ha tanta importanza?
Saluti
AS
"Se è Microsoft non funziona"

Posso chiederti xche, per te, questa cosa ha tanta importanza?
La mia prof di inglese ha sempre detto che ero un perfezionista.
Anzi, lei mi chiamava "perfettino". Io sono ancora innamorato di
lei e non mi va proprio giù l'idea di deluderla.
Alla base dell'efficienza di un programma c'è il suo ingombro.
Molte volte, scegliere di ottimizzare per velocità piuttosto che
per dimensione non è la scelta migliore. Un programma
ingombrante è fastidioso per l'utente che lo deve maneggiare
(trasportare, installare ed eseguire) e per la macchina che
"fatica" a prelevarlo dalla memoria di massa e a
immagazzinarlo in memoria centrale: quando lo spazio
scarseggia l'hard disk goregheggia!
E' anche una questione di eleganza: pensa alle demo che
partecipano al "The Party" in Europa del Nord: all'edizione
TP64K vengono presentati eseguibili di dimensioni non superiori
ai 64 Kb dove vengono riprodotti effetti grafici 2D/3D
sorprendenti.
Tu stesso scrivi che se è Microsoft non funziona. Facciamo un
po' i conti:
1. Windows 98 - 200 Mb - funzionamento buono/discreto
2. Visual Studio 6 - 400 Mb - funzionamento mediocre
3. Microsofr Office 2000 - 200-700 Mb - funzionamento pessimo
Il prestigio sta proprio nel fatto che nessuno vuole più ottimizzare
i programmi che funzionano sempre peggio anche se escono sul
mercato con grande anticipo; allora, chi lo fa riuscendo a
rimanere in carreggiata merita sicuramente punti. L'unico problema
è che non ottimizzi certamente un programma che ti fa quattro
c@##@te che compilato occupa 170 Kb!
Cmq scusa se mi sono dilungato parecchio sull'argomento ma a
me piace programmare così.
Ciao!
 _-= deep inside =-_
-                              -

C'č un modo di arrestare la voracitą di Delphi?
Certo, puoi compilare tenendo separati i "package".
--
Andrea Laforgia (ICQ 87230455)

Alla base dell'efficienza di un programma c'č il suo ingombro.
No. Alla base dell'efficienza di un programma c'e' l'algoritmo su cui
si regge e non il suo ingombro.


 C'è un modo di arrestare la voracità di Delphi?
rispolvera il buon vecchio assembly, e usa direttamente le API di Windows.
Chiaramente ci metterai 15 volte il tempo necessario per scrivere
un'applicazione, ma vuoi mettere la soddisfazione :)
Ciao, Sandro

si regge e non il suo ingombro.
La correttezza e l'efficienza minima dell'algoritmo sono due requisiti
senza i quali non esisterebbe alcun tipo di programma, quindi
l'algoritmo non è da considerarsi.
Complimenti per l'idea della separazione dei package anche se credo
proprio che combinerò un mezzo casino attuandola.
Cmq, sovraccaricando di cose inutili un'applicazione, alla fine si
rallenta la compilazione e l'esecuzione. Altrimenti perchè sarebbe più
dispendioso chiamare la funzione SinCos della libreria Math del Delphi
piuttosto che risolvere le due operazioni con l'istruzione FSINCOS del
coprocessore matematico?
Grazie cmq per il consiglio sui package. Questa sera provo e domani ti
faccio sapere. Ciàh...!


"Ukyo":
| >In che senso?Per il file exe troppo grande?
| >Posso chiederti xche, per te, questa cosa ha tanta importanza?
|
[..]
| Il prestigio sta proprio nel fatto che nessuno vuole piů ottimizzare
| i programmi che funzionano sempre peggio anche se escono sul
| mercato con grande anticipo; allora, chi lo fa riuscendo a
| rimanere in carreggiata merita sicuramente punti. L'unico problema
| č che non ottimizzi certamente un programma che ti fa quattro
| c@##@te che compilato occupa 170 Kb!
|
| Cmq scusa se mi sono dilungato parecchio sull'argomento ma a
| me piace programmare cosě.
si', anche a me, e sono un estimatore di quei 'geni'
che partecipano ai vari assembly party e simili,
ma anche li' i tempi stanno cambiando, la 'competizione'
principale ora si svolge su demo che vanno dai 5 ai 10 MB
e nonostante il nome del party, di assembly puro penso ci siano
poche righe. Per i vari 4k o 64k o simili ci sono delle sezioni
apposite chiamate old-school, questo sta a testimoniare che
l'ottimizzazione c'e' ancora, ma con le CPU e gli HD
del giorno d'oggi non e' cosi' maniacale! ;)
Come ti e' gia' stato detto dipende da cosa vuoi fare,
se proprio vuoi fare degli exe piccoli non devi usare la VCL
facendo una console application tipo questa:
dimensione 15,5KB
program NoVLC;
uses Windows;
begin
 if MessageBox(0,'Sei ancora convinto di non voler usare la
VCL?','Domanda',MB_YESNO)=IDYES
  then MessageBox(0,'Beh, auguri!','Mah...',MB_OK)
  else MessageBox(0,'Risposta esatta! Cosa vuoi che siano 300k, eh
dai!'+#13+#10+
                    'Tieni presente poi che con Delphi l''exe compilato č
tutto built-in'+
                    ' senza bisogno di DLL o cosa varie.','OK',MB_OK)
end.
oppure fare il build with runtime packages (project-options)
pero' se non ci sono sulla macchina l'exe non funzia...
Ciao! ;)
Alan Solo

un'applicazione, ma vuoi mettere la soddisfazione :)
Ti ringrazio per il consiglio. Riconosco di essere anch'io un esaltato
come te, al quale piacerebbe spaccare il culo al mondo (ma sopratutto
a Windows) con l'assembler. Riconosco però che è alquanto dispendioso
utilizzare l'assembler per cose del genere. Finché si tratta di
calcolo rapido va bene, ma qua si sta parlando di funzioni per
disegnare una finestra (neanche il finestrone del mio studio occupa
300 Kb)
Ciao e grazie!

proprio che combinerò un mezzo casino attuandola.
Non e' mia, e' Borland che l'ha pensata cosi' ;)


Finquando si parla di applicazioni che visualizzano un finto fuoco
sullo schermo va bene, ma per le operazioni complesse non ti puoi
affidare al semplice assembly. Hai bisogno di framework complessi e
funzionanti e collaudati. E te lo dice uno che ha programmato
parecchio in assembly ;) Se devo perdere un'ora a cercare il bug tra i
vari repnz, mov, lodsb, add, xor, cli, sti, & company, per avere un
paio di secondi di velocita' in piu', preferisco avere un framework
piu' lento, ma una garanzia di efficienza :)


cosi'. 
Purtroppo dovrebbe essere cosě! Una volta lo era... (quando mio padre
20 anni fa lavorava con i sistemi basati su uP Zilog).

del giorno d'oggi non e' cosi' maniacale! ;)
Si, ma vorrai pur ammettere che č un circolo vizioso (il classico
gatto che si morde la coda) che impedisce un autentico sviluppo nel
campo dei software: l'hardware si fa sempre piů potente ma, il
software si fa sempre piů pesante (richiedendo un supporto hardware
sempre maggiore)!!!
Vedi le porcherie che stanno succedendo con le schede 3D!

20 anni fa lavorava con i sistemi basati su uP Zilog).
"Non appena ci siamo messi a programmare, ci siamo accorti con immenso
stupore che mettere a punto i programmi non era facile come avevamo
immaginato. Bisognava scoprire un modo per eliminare i bachi e
correggere gli errori. Ricordo l'attimo preciso in cui mi sono reso
conto che una buona parte della mia vita sarebbe stata impiegata nel
ricercare gli errori contenuti nei miei programmi"
[Maurice Wilkes, "Memoirs of a Computer Pioneer"]
Come vedi, non lo e' mai stato :)



Ah, si?!?  ;-P
L'allegato che ti mando con questo messaggio è una parte dell cuore
del mio motore grafico. L'ho pensato alla tenera età di 17 anni
(l'anno scorso) mentre ero nel mio pensatorio (il ce55o). Dapprima
scritto in pascal, ho preferito tradurlo in assembler e ottimizzarlo
personalmente per renderlo quanto più veloce possibile (nel limite
delle mie conoscenze).
Il codice che vedi esegue le rotazioni 2D attraverso l'uso di
istruzioni 80387 (FPU). Realizzo una rotazione solida applicando tre
rotazioni planari. Nel file completo ci sono altre tre procedure
dichiarate Pascal ma integralmente implementate assembly che
trasformano le coordinate da fisiche a coordinate schermo.
Divertiti		:->
(dimmi cosa ne pensi giacchè; se riesci a vedere qc che può essere
velocizzato avvertimi).
Ciao!

del mio motore grafico.
Non spedire allegati ai tuoi messaggi.
E' vietato dal GCN (nonche' dalla netiquette).
Credo che il senso del mio messaggio fosse abbastanza chiaro : quando
ti trovi a dover svolgere delle operazioni "complesse", non puoi
affidarti al "semplice" assembly, ma hai bisogno di un framework
complesso.


"Ukyo":
| > ...
| >l'ottimizzazione c'e' ancora, ma con le CPU e gli HD
| >del giorno d'oggi non e' cosi' maniacale! ;)
|
| Si, ma vorrai pur ammettere che è un circolo vizioso (il classico
| gatto che si morde la coda) che impedisce un autentico sviluppo nel
| campo dei software: l'hardware si fa sempre più potente ma, il
| software si fa sempre più pesante (richiedendo un supporto hardware
| sempre maggiore)!!!
eh, gia'
ma come ripeto, dipende da cosa vuoi fare...
scrivere un gestionale in assembly sarebbe un suicidio ;)
cmq il compilatore di delphi (da quanto ne so)
produce un codice molto veloce, quindi non preoccuaparti
+ di tanto dell'ottimizzazione, ci hanno già pensato
i programmatori di borland :)
Ciao,
Alan Solo

complesso.
Da chi è vietato mandare allegati ? E perchè?
Cos'è la sigla GCN?

Cos'è la sigla GCN?
Gruppo di Coordinamento Nazionale.
E' vietato nella gerarchia it.* ed e' anche giusto, a mio avviso,
visto che gruppi come questo non servono a scambiarsi file binari.
Esistono gruppi appositi.
--
Andrea Laforgia (ICQ 87230455)
------------------------------ 
#exclude <windows.h>

Gruppo di Coordinamento Nazionale.
Ops. Gruppo di Coordinamento NEWS-IT


 C'è un modo di arrestare la voracità di Delphi?
al limite puoi usare la compilazione che esclude i package che però devi
portarti dietro come file anche se l'exe risultante è di pochissimi Kb.
Ti saluto.....buona settimana.
Ciaoooo !!!
Antonio Tarolla

 funzionanti e collaudati.
Sono d'accordo. Una cosa e' fare routine numeriche, per le quali l'assembly
puo' andare pure bene (oddio, lo sforzo necessario per la programmazione e
debug e' notevole, soprattutto se si deve emulare un motore che gestisce
numeri reali), ma se devo scrivere un programma gestionale non vado certo a
farlo in assembly, sarebbe ridicolo :)
Ciao, Sandro

Considerando che il software e' fatto a strati, e che i programmatori che
conoscono o hanno capacita' di sviluppare algoritmi di una certa efficienza
non sono molti (basta guardare nei listati dei vari programmi free che si
trovano in giro, spesso si preferisce qualcosa di piu' comprensibile dal
punto di vista della comprensibilita' del sorgente che di veloce e
ottimizzato), c'e' anche da considerare che il compilatore ha un suo peso
nel risultato finale. Pensa al VB che genera un P-CODE che il motore di
runtime deve occuparsi di eseguire reinterpretandolo, e pensa al dispendio
di risorse che questo genera. Delphi almeno genera linguaggio macchina puro,
tra l'altro tagliando dall'exe tutto il codice non usato, variabili,
procedure, ecc.
Ciao, Sandro

Ti ringrazio. Sei uno dei pochi che mi ha risposto decentemente e
senza mostarsi troppo la testa.
Alla prossima	:-)
PS: Un consiglio. Non usare Outlook; per le news usa Forté FreeAgent.
E' un ottimo freeware da 1,21 Mb e se mi dai l'indirizzo te lo mando
via e-mail.
Ciŕh...!

Già, hai ragione. Parlando con un mio amico è uscito fuori che è buona
norma e garantisce l'assenza di virus vaganti all'interno del
newsgroup.
Cmq me ne ricorderò per i prossimi	;-)
Grazie e ciao!!!


kakkyo, allora possiamo considerarci fortunati!?!	:-P
ciao!