我正在尝试解决System.Classes.pas中一个已知的丑陋性能限制,它具有20世纪80年代的常量缓冲区限制($ F000),如下所示:
function TStream.CopyFrom(const Source: TStream; Count: Int64): Int64;
const
MaxBufSize = $F000;
....
这导致我们的Delphi应用程序遭受重大性能损失。在delphi XE2到XE5中,我们能够修改它并使用以下方法之一:
我可以修改Delphi源代码,然后通过从批处理文件调用dcc32.exe,重建Delphi库文件夹中的System.Classes.dcu文件。我意识到这很丑陋而且我不喜欢这样做,但我不喜欢RTL中这个丑陋的性能问题,而且我们的用户无法忍受它导致的性能问题。
我可以尝试在我的项目搜索路径中的某处放置一个经过修改的system.classes.pas文件。
现在,在Delphi XE6中,上述两种方法都不适合我,这可能要归功于一些内部编译器的更改。我在其uses子句中包含System.Contnrs的最小命令行应用程序中获得的错误是:
[dcc32 Fatal Error] System.Classes.pas(19600): F2051 Unit System.Contnrs was compiled with a different version of System.Classes.TComponent
重现此问题的示例程序(假设您已修改了System.Classes.pas并更改了MaxBufSize常量),如下所示:
program consoletestproject;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.Contnrs,
System.SysUtils;
var
List:System.Contnrs.TObjectList;
begin
WriteLn('Hello world');
end.
同样,这个问题在Delphi XE6中很容易重现,但在XE5或更早版本中不是问题。
当您绝对必须使用System.Classes.pas或System.SysUtils.pas或其他一些非常低级别的单元的修改副本解决基本RTL或VCL限制时,建议的做法是什么? (是的,我知道如果你不必这样做,你就不应该这样做,不要为讲课而烦恼。)
是否有一组神奇的命令行参数可以通过命令行中的“dcc32.exe”使用,以生成一个修改后的DCU,它将与上面的应用程序示例正确链接?
作为第二个问题,是否有.dcu文件没有源存在,当一个人尝试这样做时会破坏,在这种情况下,上述所有的答案是,“你无法解决这个问题,如果有一个bug在RTL中,你运气不好“?
一种可能的解决方法是在项目搜索路径(或库路径)中包含“$(BDS)\ source \ rtl \ common”,强制每个损坏的(需要重新编译)DCU重建每个时间,但这看起来很丑陋和错误。