|
|
 | Stor exe fil og stort memory footprint fra~
Fra : Ukendt |
Dato : 09-08-04 13:26 |
|
Jeg har kodet en lille mp3 afspiller som bruger fmod. Problemet er at
når jeg compiler det fylder min exe fil 420kb og når den køre bruger den
3340kb ram. Jeg synes det er utroligt meget da programmet kun er på ca.
40linjer og bruger et shared lib.
Jeg bruger MinGW til at compile med. jeg compiler med følgende kommandoer:
g++ -O2 -c main.cpp
g++ -o main main.o -lfmod
---- Kode (main.cpp) ----
#include <iostream>
#include <fstream>
#include "fmod.h"
FSOUND_STREAM* handle;
int main(int argc, char* argv[])
{
if(argc < 1){
std::cout << "Ingen fil" << std::endl;
return 1;
}
// test om filen eksistere og kan læses
std::ifstream test(argv[1]);
if( !test ){
std::cout << "Kunne ikke åbne filen" << std::endl;
return 1;
}
FSOUND_SetOutput(FSOUND_OUTPUT_DSOUND);
//init FMOD sound system
FSOUND_Init(44100, 32, 0);
//load and play sample
handle = FSOUND_Stream_Open(argv[1], 0, 0, 0);
FSOUND_Stream_Play(0, handle);
char* key;
std::cout << "Tryk enter for at stoppe" << std::endl;
std::cin.getline(key, 1);
//clean up
FSOUND_Stream_Close(handle);
FSOUND_Close();
return 0;
}
---- Kode slut ----
| |
 Klaus Petersen (09-08-2004)
| Kommentar
Fra : Klaus Petersen |
Dato : 09-08-04 15:25 |
|
> Jeg har kodet en lille mp3 afspiller som bruger fmod. Problemet er at
> når jeg compiler det fylder min exe fil 420kb og når den køre bruger den
> 3340kb ram.
Når man linker et bibliotek til en eksekverbar fil, linkes der ofte også en
masse funktioner fra biblioteket, som programmet dog ikke bruger.
Mit bud er, at det er årsagen til din eksekverbare fil fylder så meget.
Man kan bede linkeren om at strippe funktioner fra, som ikke bliver brugt.
Mener det er option 's' eller --stripped:
g++ -s -o main main.o -lfmod
Mht. ram'en ... kunne det tænkes at den henter hele mp3 filen ind i
hukommelsen? Det kunne forklare hukommelsesforbruget.
| |
Ukendt (09-08-2004)
| Kommentar
Fra : Ukendt |
Dato : 09-08-04 19:36 |
|
Klaus Petersen wrote:
>>Jeg har kodet en lille mp3 afspiller som bruger fmod. Problemet er at
>>når jeg compiler det fylder min exe fil 420kb og når den køre bruger den
>>3340kb ram.
>
>
> Når man linker et bibliotek til en eksekverbar fil, linkes der ofte også en
> masse funktioner fra biblioteket, som programmet dog ikke bruger.
>
> Mit bud er, at det er årsagen til din eksekverbare fil fylder så meget.
>
> Man kan bede linkeren om at strippe funktioner fra, som ikke bliver brugt.
> Mener det er option 's' eller --stripped:
>
> g++ -s -o main main.o -lfmod
>
> Mht. ram'en ... kunne det tænkes at den henter hele mp3 filen ind i
> hukommelsen? Det kunne forklare hukommelsesforbruget.
>
>
Ram forbruget er ens ligemeget om det er en 50kb fil eller en på 5mb
| |
Ukendt (09-08-2004)
| Kommentar
Fra : Ukendt |
Dato : 09-08-04 19:38 |
|
> Man kan bede linkeren om at strippe funktioner fra, som ikke bliver brugt.
> Mener det er option 's' eller --stripped:
>
> g++ -s -o main main.o -lfmod
>
> Mht. ram'en ... kunne det tænkes at den henter hele mp3 filen ind i
> hukommelsen? Det kunne forklare hukommelsesforbruget.
>
>
Ja det hjalp at strippe filen, så kom den ned på 230kb stadig meget
synes jeg men en stor forbedring.
| |
 Igor V. Rafienko (10-08-2004)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 10-08-04 04:12 |
|
[ Frederik B. Sørensen ]
[ ... ]
> Ja det hjalp at strippe filen, så kom den ned på 230kb stadig meget
> synes jeg men en stor forbedring.
Hvordan er disse 230kb fordelt på forskjelige seksjoner? Dvs. .text,
..data, .bss, etc. (eller hva det nå enn de heter på den platformen du
måtte generere koden for).
ivr
--
<html><form><input type crash></form></html>
| |
Ukendt (10-08-2004)
| Kommentar
Fra : Ukendt |
Dato : 10-08-04 17:51 |
|
Igor V. Rafienko wrote:
> [ Frederik B. Sørensen ]
>
> [ ... ]
>
>
>>Ja det hjalp at strippe filen, så kom den ned på 230kb stadig meget
>>synes jeg men en stor forbedring.
>
>
>
> Hvordan er disse 230kb fordelt på forskjelige seksjoner? Dvs. .text,
> .data, .bss, etc. (eller hva det nå enn de heter på den platformen du
> måtte generere koden for).
>
>
>
>
>
> ivr
Hvordan undersøger jeg det?
| |
Bertel Brander (10-08-2004)
| Kommentar
Fra : Bertel Brander |
Dato : 10-08-04 21:46 |
|
Frederik B. Sørensen wrote:
>
> Hvordan undersøger jeg det?
Du bruger programmet size, hvis jeg kører det for programmet
det.exe (size det.exe) får jeg at vide:
text data bss dec hex filename
209920 9728 19120 238768 3a4b0 det.exe
Det gør mig dog ikke ret meget klogere...
/b
| |
Igor V. Rafienko (11-08-2004)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 11-08-04 00:01 |
|
[ Bertel Brander ]
[ ... ]
> Du bruger programmet size,
Nå ja. Man bruker det verktøyet som kommer med omgivelsen. For gcc vil
det typisk være objdump fra binutils, fx. Akkurat nå på jobben bruker
jeg linkeren til VC8.0 til å finne ut av slikt.
> hvis jeg kører det for programmet det.exe (size det.exe) får jeg at
> vide:
>
> text data bss dec hex filename
> 209920 9728 19120 238768 3a4b0 det.exe
>
> Det gør mig dog ikke ret meget klogere...
Ok, nå ser man at mesteparten av plassen brukes av koden (ok, det
finnes arkitekturer som plasserer data i .text, men det er nå en annen
sak). Siden det er høyst sannsynlig biblioteket som er dratt inn som
fyller mesteparten av den plassen, kan man undersøke om ikke det går
an å spørre linkeren og/eller kompilatoren om å ta inn kun de rutinene
som er nødvendige (og da kanskje linke inn statisk).
ivr
--
<html><form><input type crash></form></html>
| |
Bertel Brander (11-08-2004)
| Kommentar
Fra : Bertel Brander |
Dato : 11-08-04 00:19 |
|
Igor V. Rafienko wrote:
> [ Bertel Brander ]
>
> [ ... ]
>
>
>>Du bruger programmet size,
>
>
>
> Nå ja. Man bruker det verktøyet som kommer med omgivelsen. For gcc vil
> det typisk være objdump fra binutils, fx. Akkurat nå på jobben bruker
> jeg linkeren til VC8.0 til å finne ut av slikt.
>
size er et gnu tool der kommer sammen med mingw
mingw har også objdump
/b
| |
Ukendt (11-08-2004)
| Kommentar
Fra : Ukendt |
Dato : 11-08-04 00:15 |
|
Frederik B. Sørensen wrote:
> Igor V. Rafienko wrote:
>
>> [ Frederik B. Sørensen ]
>>
>> [ ... ]
>>
>>
>>> Ja det hjalp at strippe filen, så kom den ned på 230kb stadig meget
>>> synes jeg men en stor forbedring.
>>
>>
>>
>>
>> Hvordan er disse 230kb fordelt på forskjelige seksjoner? Dvs. .text,
>> .data, .bss, etc. (eller hva det nå enn de heter på den platformen du
>> måtte generere koden for).
>>
>>
>>
>>
>>
>> ivr
>
>
> Hvordan undersøger jeg det?
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00032800 00401000 00401000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 00001400 00434000 00434000 00032c00 2**4
CONTENTS, ALLOC, LOAD, DATA
2 .bss 000049f0 00436000 00436000 00000000 2**4
ALLOC
3 .idata 00000a00 0043b000 0043b000 00034000 2**2
CONTENTS, ALLOC, LOAD, DATA
Det er hvad jeg får på mit program
| |
Ukendt (11-08-2004)
| Kommentar
Fra : Ukendt |
Dato : 11-08-04 00:21 |
|
Outputtet fra size er lidt mere læseligt
text data bss dec hex filename
206848 7680 18928 233456 38ff0 main.exe
| |
|
|