blocks|key|177228|text|这只是语言设计上的不同。要比较“X语言”比“Y语言”更快是很难的，就像数独的解算器一样。性能的提高实际上取决于实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|177229|但是，PHP数组在内部存储为有序散列。|offset|length|177230|如果您正在寻找数组和集合的性能增益，请尝试查看一些这些。它们可能更适合您的数据集。这是关于选择正确的工具--+PHP数组似乎是人们喜欢将所有数据都塞进的“所有”结构，这是一个我不同意的模式。|177231|entityMap|0|LINK|mutability|MUTABLE|url|https://svn.php.net/repository/php/php-src/branches/PHP_5_3/Zend/zend_hash.h|1|http://us2.php.net/manual/en/spl.datastructures.php^0|0|E|4|0|0|P|2|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

It's just a difference in language design. It's difficult to compare "language X" is faster than "language Y" in terms of something like a Sudoku solver. The performance gain really boils down to implementation. 

However, PHP arrays are stored internally as <a href="https://svn.php.net/repository/php/php-src/branches/PHP_5_3/Zend/zend_hash.h" rel="nofollow">ordered hashes</a>. 

If you're looking for a performance gain with arrays and sets, try looking at some of <a href="http://us2.php.net/manual/en/spl.datastructures.php" rel="nofollow">these</a>. They might fit your dataset better. It's about choosing the right tool - PHP arrays seem to be this "catch-all" structure that people love to shove all their data in, and it's a pattern with which I disagree.

blocks|key|2001612|text|也许其中一种SPL数组类型更适合您？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2001613|PHP+SPL手册|offset|length|2001614|编辑：更仔细地观察它，SplFixedArray将是一个很好的选择，在sudoku实现中，您将知道数组的大小。它自己说它会更快。然而，正如其他人所说--如果不看算法，我们怎么能确定数组是问题所在呢？|style|BOLD|2001615|数组的性能比较与SplFixedArray|2001616|SPL+-代表标准PHP库，它不太可怕|2001617|entityMap|0|LINK|mutability|MUTABLE|url|http://php.net/manual/en/book.spl.php|1|http://blog.shay.co/phps-native-array-vs-splfixedarray-performance/^0|0|0|9|0|0|0|3|0|3|4|1|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|F|3|G|5|6|7|12|8|@$D|13|E|14|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@$D|16|E|17|1|18]]|A|$]]|$1|L|3|M|5|6|7|19|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]|V|$5|Q|R|S|A|$T|W]]]]

Maybe one of the SPL array types would have suited you better?

<a href="http://php.net/manual/en/book.spl.php" rel="nofollow">PHP SPL manpage</a>

Edit: Looking more closely at it, the SplFixedArray would be a good choice for a sudoku implementation where you will know the size of the array. It says itself that it would be faster. However as others have said - without looking at the algorithm how can we be sure that the arrays were the problem?

<a href="http://blog.shay.co/phps-native-array-vs-splfixedarray-performance/" rel="nofollow">Perfomance comparison</a> of array vs SplFixedArray

SPL - stands for Standard PHP Library, its nothing too scary

blocks|key|77012|text|我想，php是作为html页面的模板引擎而设计的。它必须非常简单，非常容易使用，所有必要的构造/功能需要一个典型的web应用程序，迭代数据库字段，等等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|77013|对于php应用程序来说，速度从来不是问题，因为文件系统、数据库访问和web服务通常比php+cpu处理慢得多。|77014|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I guess, php was designed as a template engine for html pages. It has to be very simple, and very easy to use, with all necessary constructs / functions needed for a typical web application, iterating thorugh database fields, etc...

The speed was never an issue for php applications, as filesystems, database access and web services are uasually slower than php cpu processing alone.

blocks|key|2001628|text|从理论上讲，具有内部索引0+..+length+-+1的数组只是关联数组的一种特例，即具有键0+..+length+-+1的关联数组。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2001629|当然，查找算法更复杂，在最坏的情况下通常不能得到O(1)。但是，如果哈希函数和哈希表实现是好的(在广泛使用的语言实现中，它可能是一种基本的数据类型)，那么O(1)就会被重新化。此外，当大多数或所有键都是整数时，完全可以在散列表场景后面使用(非关联的)数组，这就排除了使用这些索引操作时90%25的开销。Lua+5会这样做，我不知道当前的PHP版本是否也这么做。|2001630|如果所有这些都还不够，而且查找速度仍然太慢，那么另一个答案是:改进您的算法。(真的。不要轻率地选择其他选择。)您还可以找到一个提供库的库(尽管它是否真的更快(特别是如果它是用PHP编写的)，或者您可以将计算紧张的部分移到另一种语言中(如果您需要这样做，也可以一路使用C编写它)。但是一般来说，哈希表应该足够快。|2001631|entityMap^0|C|F|1A|F|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

An array with intral indices <code>0 .. length - 1</code> is, in theory, just a special case of associative arrays, namely an associative array with the keys <code>0 .. length - 1</code>.

Of course the lookup algorithm is more involved, and generally you can't get O(1) in the worst case. But you do get armortized O(1) provided the hash function and hashtable implementation is any good (and in widely-used language implementations where it's a fundamental data type, it probably is). Also, it is entirely possible to use an (non-associative) array behind the scence for hash tables when most or all keys are integers, which rules out 90% of the overhead while operating with these indices. Lua 5 does it, I don't know if current PHP versions do it too.

If all that isn't enough and lookups are still too slow for your purpose, then the other answer apply: Improve your algorithm. (Really. Don't move to other options lightheartedly.) You may also be able to find a library that provides one (although it's questionable whether it's really faster, especially if it's written in PHP) or you may move the computationally intense parts into another language (and if you need to do that, you may as well go all the way and write it in C). But generally, a hashtable should be fast enough.

blocks|key|2001439|text|这取决于你是如何尝试随机化的。如果你使用大循环，你不应该被告知它是缓慢的。为此目的使用rand()|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2001440|entityMap^0|17|6|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

It depends on how did you try to randomize it. If you used big for loop you shouldn't be suprised it was slow. Use <code>rand()</code> for this purpose

The PHP array is in fact an ordered map that associates values to keys. The access to random numerical indices is considerably slower than it is in languages like Java. Even Javascript array access is significantly faster than PHP. I experienced the slowness of PHP when I programmed Sudoku solutions on the server and switched finally to Python, that was also faster than PHP.

What is the reason that PHP does not provide a proper random access array (for numerical indices)?

To clarify: I am not speaking about randomnes of the entries. I mean direct access via computed indices, e.g. having an array <code>a</code> of 81 values (Sudoku board) and accessing any value <code>a[i]</code> directly without searching a map.

Why there is not a random access array in PHP?

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

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

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

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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

PHP数组实际上是一个有序的映射，它将值与键关联起来。访问随机数值索引的速度比Java等语言慢得多。甚至Javascript数组访问也比PHP快得多。当我在服务器上编写Sudoku解决方案并最终切换到Python时，我体验了PHP的缓慢，这也比PHP更快。PHP没有提供适当的随机访问数组(用于数字索引)的原因是什么？我要澄清的是:我说的不是随机的条目。我指的是通过计算索引直接访问，例如有一个81值

问为什么PHP中没有随机访问数组？
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么PHP中没有随机访问数组？EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么PHP中没有随机访问数组？
EN