blocks|key|91195|text|在没有更多细节的情况下，很难对这个问题作出权威性的回答。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|91196|但是，需要考虑的一个因素是描述了这里的Windows前台优先级提升。|offset|length|91197|您可能需要阅读Russinovich的书中关于进程/线程的章节，特别是关于调度的内容。你可以在网上找到这本书的PDF(两本书合在一起构成了整本书)。我相信最新版(或紧靠最新版)涵盖了Win+7中的变化。|91198|entityMap|0|LINK|mutability|MUTABLE|url|https://msdn.microsoft.com/en-us/library/windows/desktop/ms684828(v=vs.85).aspx)^0|0|G|2|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

It will be very difficult to give an authoritative answer to this question without a lot more details.

However a factor to consider is the Windows foreground priority boost described <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms684828(v=vs.85).aspx" rel="nofollow">here</a>. 

You may want to read Russinovich's book chapter on processes/threads, in particular the stuff on scheduling. You can find PDFs of the book online (there are two that together make up the whole book). I believe the latest (or next to latest) edition covers changes in Win 7.

blocks|key|2117514|text|我分离了一些代码来再现这一点，它最终归结为对数据库引擎的调用来查找字段定义(TTable方法FindField和FieldByName)。当在服务应用程序上运行而不是在GUI应用程序上运行时，这些操作在有很多字段的表上花费的时间要长得多。我设计了自己的方法来存储从字段名到字段定义的映射，因为我总是用一个中央例程打开数据库。我使用了每个表(所有BCB对象通用的)标记属性索引的字符串数组，其中每个字符串由；字段名；字段号；成对组成，然后执行字段名的.Pos来获取字段号。字段号为零填充，宽度为4。整个应用程序及其所有数据库只需使用几百KB的RAM。一旦到位，服务应用程序将以与GUI应用程序相同的速度运行。我唯一能想到的解释就是，服务应用程序本身和它们产生的任何进程都有一个固定的堆(我想我在某个地方默认读到了48+48MBytes+)。由于有很多字段，内存溢出，不得不在磁盘上调用VM。GUI应用程序没有这样的限制，完全可以在实际内存中进行查找。不过，我可能完全错了。我学到的一件事是，FieldByName和FindField是昂贵的调用TTable函数，现在我用自己的机制取代了它们，这些机制似乎工作得更好，速度更快。这是我的查找例程:-|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2117515|AnsiString+fldsbytag[MXSPRTBLS%2B100];

TField+*fldfromtag(TAdsTable+*tbl,AnsiString+fld)
{
++int+fi=fldsbytag[tbl->Tag].Pos(";"%2Bfld.UpperCase()%2B";"),gi;
++if+(fi==0)+return+tbl->FindField(fld);
++gi=StrToIntDef(fldsbytag[tbl->Tag].SubString(fi%2Bfld.Length()%2B2,4),-1);
++if+(gi<0+%7C%7C+gi>=tbl->Fields->Count)+return+tbl->FindField(fld);
++return+tbl->Fields->Fields[gi];
}|code-block|syntax|javascript|2117516|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I isolated code to reproduce this, and it eventually boiled down to calls to the database engine to lookup a field definition (TTable methods FindField and FieldByName). These took much longer on a table with a lot of fields when run on a service app instead of a GUI app. I devised my own method to store mappings from field names to field definitions, since I always opened my databases with a central routine. I used an array of strings indexed by the Tag property on each table (common to all BCB objects), where each string was composed of ;fieldname;fieldnumber; pairs, and then did a .Pos of the field name to get the field number. fieldnumber is zero-padded to a width of 4. This only uses a few hundred KB of RAM for the entire app and all of its databases. Once in place, the service app runs at the same speed as the GUI app. The only thing I can think of that may explain this, is that service apps have a fixed heap (I think I read 48MBytes somewhere by default) for themselves and any process they spawn. With lots of fields, the memory overflowed and had to thrash to VM on the disk. The GUI app had no such limit and was able to do the lookup entirely in real memory. However, I maybe completely wrong. One thing I have learnt is that FieldByName and FindField are expensive TTable functions to call, and I have now supplanted them all with my own mechanism which seems to work much better and much faster. Here is my lookup routine :-

<pre><code>AnsiString fldsbytag[MXSPRTBLS+100];

TField *fldfromtag(TAdsTable *tbl,AnsiString fld)
{
 int fi=fldsbytag[tbl-&gt;Tag].Pos(";"+fld.UpperCase()+";"),gi;
 if (fi==0) return tbl-&gt;FindField(fld);
 gi=StrToIntDef(fldsbytag[tbl-&gt;Tag].SubString(fi+fld.Length()+2,4),-1);
 if (gi&lt;0 || gi&gt;=tbl-&gt;Fields-&gt;Count) return tbl-&gt;FindField(fld);
 return tbl-&gt;Fields-&gt;Fields[gi];
}
</code></pre>

I have written a service application in Borland C++. It works fine. In the ServiceStart(TService *Sender,bool &amp;Started) routine, I call mjwinrun to launch a process which picks up and processes macros. This process has no UI and any errors are logged to a file. It continues to run, until the server is restarted, shut down, or the process is terminated using Task Manager. Here is mjwinrun :-

<pre><code>int mjwinrun(AnsiString cmd)
{
 STARTUPINFO mjstupinf; PROCESS_INFORMATION mjprcinf;
 memset(&amp;mjstupinf,0,sizeof(STARTUPINFO)); mjstupinf.cb=sizeof(STARTUPINFO);
 if (!CreateProcess(NULL,cmd.c_str(),NULL,NULL,TRUE,0,NULL,GetCurrentDir().c_str(),&amp;mjstupinf,&amp;mjprcinf))
 {
 LogMessage("Could not launch "+cmd); return -1;
 }
 CloseHandle(mjprcinf.hThread); CloseHandle(mjprcinf.hProcess);
 return mjprcinf.dwProcessId;
}
</code></pre>

cmd is the command line for launching the macro queue processor. I used a macro that is CPU/Memory intensive and got it to write its timings to a file. Here is what I found :-

1) If the macro processor is launched from the command line within a logged on session, no matter what Windows core it is running under, the macro is completed in 6 seconds.

2) If the macro processor is launched from a service starting up on Vista core or earlier (using mjwinrun above), the macro is completed in 6 seconds.

3) If the macro processor is launched from a service starting up on Windows 7 core or later (using mjwinrun above), the macro is completed in more than 18 seconds.

I have tried all the different flags for CreateProcess and none of them make a difference. I have tried all different accounts for the service and that makes no difference. I tried setting all of the various priorities for tasks, I/O and Page, but they all make no difference. It's as if the service's spawned processes are somehow throttled, not in I/O terms, but in CPU/memory usage terms. Any ideas what changed in Windows 7 onwards?

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

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我已经用Borland C++编写了一个服务应用程序。效果很好。在ServiceStart(TService *Sender，bool &Started)例程中，我调用mjwinrun来启动一个进程，该进程可以拾取并处理宏。此进程没有UI，任何错误都会记录到文件中。它继续运行，直到服务器重新启动、关闭或使用任务管理器终...

问Windows服务生成的进程运行速度比GUI生成的进程慢3到4倍
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Windows服务生成的进程运行速度比GUI生成的进程慢3到4倍EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Windows服务生成的进程运行速度比GUI生成的进程慢3到4倍
EN