c++ - Process spawned by Windows service runs 3 to 4 times more slowly than spawned by GUI -

i have written service application in borland c++. works fine. in servicestart(tservice *sender,bool &started) routine, call mjwinrun launch process picks , processes macros. process has no ui , errors logged file. continues run, until server restarted, shut down, or process terminated using task manager. here mjwinrun :-

int mjwinrun(ansistring cmd) {   startupinfo mjstupinf; process_information mjprcinf;   memset(&mjstupinf,0,sizeof(startupinfo)); mjstupinf.cb=sizeof(startupinfo);   if (!createprocess(null,cmd.c_str(),null,null,true,0,null,getcurrentdir().c_str(),&mjstupinf,&mjprcinf))   {     logmessage("could not launch "+cmd); return -1;   }   closehandle(mjprcinf.hthread); closehandle(mjprcinf.hprocess);   return mjprcinf.dwprocessid; } 

cmd command line launching macro queue processor. used macro cpu/memory intensive , got write timings file. here found :-

1) if macro processor launched command line within logged on session, no matter windows core running under, macro completed in 6 seconds.

2) if macro processor launched service starting on vista core or earlier (using mjwinrun above), macro completed in 6 seconds.

3) if macro processor launched service starting on windows 7 core or later (using mjwinrun above), macro completed in more 18 seconds.

i have tried different flags createprocess , none of them make difference. have tried different accounts service , makes no difference. tried setting of various priorities tasks, i/o , page, make no difference. it's if service's spawned processes somehow throttled, not in i/o terms, in cpu/memory usage terms. ideas changed in windows 7 onwards?

i isolated code reproduce this, , boiled down calls database engine lookup field definition (ttable methods findfield , fieldbyname). these took longer on table lot of fields when run on service app instead of gui app. devised own method store mappings field names field definitions, since opened databases central routine. used array of strings indexed tag property on each table (common bcb objects), each string composed of ;fieldname;fieldnumber; pairs, , did .pos of field name field number. fieldnumber zero-padded width of 4. uses few hundred kb of ram entire app , of databases. once in place, service app runs @ same speed gui app. thing can think of may explain this, service apps have fixed heap (i think read 48mbytes somewhere default) , process spawn. lots of fields, memory overflowed , had thrash vm on disk. gui app had no such limit , able lookup entirely in real memory. however, maybe wrong. 1 thing have learnt fieldbyname , findfield expensive ttable functions call, , have supplanted them own mechanism seems work better , faster. here lookup routine :-

ansistring fldsbytag[mxsprtbls+100];  tfield *fldfromtag(tadstable *tbl,ansistring fld) {   int fi=fldsbytag[tbl->tag].pos(";"+fld.uppercase()+";"),gi;   if (fi==0) return tbl->findfield(fld);   gi=strtointdef(fldsbytag[tbl->tag].substring(fi+fld.length()+2,4),-1);   if (gi<0 || gi>=tbl->fields->count) return tbl->findfield(fld);   return tbl->fields->fields[gi]; }