登录
当前位置： 首页 > 面试题库 >

Python读取速度慢的问题

柯天宇
2023-03-14
问题内容：

在上一个线程之后，我将问题归结为无精打采，在从Perl脚本迁移到Python时，我发现在Python中处理文件存在很大的性能问题。在Ubuntu
Server上运行它。

注意：这不是X线程还是Y线程，我需要从根本上知道这是怎么回事，或者我是否在做一些愚蠢的事情。

我创建了50,000个10kb文件的测试数据（这反映了我正在处理的平均文件大小）：

mkdir 1
cd 1
for i in {1..50000}; do dd if=/dev/zero of=$i.xml bs=1 count=10000; done
cd ..
cp -r 1 2

尽可能简单地创建我的2个脚本：

佩尔

foreach my $file (<$ARGV[0]/*.xml>){
    my $fh;
    open($fh, "< $file");
    my $contents = do { local $/; <$fh> };
    close($fh);
}

蟒蛇

import glob, sys
for file in glob.iglob(sys.argv[1] + '/*.xml'):
    with open(file) as x:
        f = x.read()

然后，我清除了缓存并运行了2个Slurp脚本，在每次运行之间，我使用以下命令再次清理了缓存：

sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

然后进行监视，以确保每次都从磁盘读取所有内容：

sudo iotop -a -u me

我在具有RAID 10磁盘的物理计算机上尝试了此操作，并在我设置为VM在RAID 1
SSD上的全新VM上进行了此测试，因为物理服务器的运行速度几乎相同，但是我的VM进行了测试。

$ time python readFiles.py 1
    real    5m2.493s
    user    0m1.783s
    sys     0m5.013s

$ time perl readFiles.pl 2
    real    0m13.059s
    user    0m1.690s
    sys     0m2.471s

$ time perl readFiles.pl 2
    real    0m13.313s
    user    0m1.670s
    sys     0m2.579s

$ time python readFiles.py 1
    real    4m43.378s
    user    0m1.772s
    sys     0m4.731s

我在iotop上注意到，当Perl运行DISK READ时约为45 M / s，IOWAIT约为70％，而运行Python DISK READ时约为2M /
s，而IOWAIT为97％。将它们煮成我所能理解的那么简单，我不确定该从哪里去。

如果相关的话

$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2

$ perl -v
This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi

要求的其他信息

我运行了strace并获取了文件1000.xml的信息，但是所有这些似乎都做相同的事情：

佩尔

$strace -f -T -o trace.perl.1 perl readFiles.pl 2

32303 open("2/1000.xml", O_RDONLY)      = 3 <0.000020>
32303 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff7f6f7b90) = -1 ENOTTY (Inappropriate ioctl for device) <0.000016>
32303 lseek(3, 0, SEEK_CUR)             = 0 <0.000016>
32303 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000016>
32303 fcntl(3, F_SETFD, FD_CLOEXEC)     = 0 <0.000017>
32303 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000030>
32303 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 <0.005323>
32303 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 1808 <0.000022>
32303 read(3, "", 8192)                 = 0 <0.000019>
32303 close(3)                          = 0 <0.000017>

蟒蛇

$strace -f -T -o trace.python.1 python readFiles.py 1

32313 open("1/1000.xml", O_RDONLY)      = 3 <0.000021>
32313 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000017>
32313 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000019>
32313 lseek(3, 0, SEEK_CUR)             = 0 <0.000018>
32313 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000018>
32313 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa18820a000 <0.000019>
32313 lseek(3, 0, SEEK_CUR)             = 0 <0.000018>
32313 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 <0.006795>
32313 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 1808 <0.000031>
32313 read(3, "", 4096)                 = 0 <0.000018>
32313 close(3)                          = 0 <0.000027>
32313 munmap(0x7fa18820a000, 4096)      = 0 <0.000022>

我注意到的一个不同之处（不确定它是否相关）是Perl在开始打开它们之前对所有文件运行了它，而python却没有：

32303 lstat("2/1000.xml", {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000022>

还用-c运行了strace（只接了几个电话）：

佩尔

$ time strace -f -c perl readFiles.pl 2
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 44.07    3.501471          23    150018           read
 12.54    0.996490          10    100011           fstat
  9.47    0.752552          15     50000           lstat
  7.99    0.634904          13     50016           open
  6.89    0.547016          11     50017           close
  6.19    0.491944          10     50008     50005 ioctl
  6.12    0.486208          10     50014         3 lseek
  6.10    0.484374          10     50001           fcntl

real    0m37.829s
user    0m6.373s
sys     0m25.042s

蟒蛇

$ time strace -f -c python readFiles.py 1
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 42.97    4.186173          28    150104           read
 15.58    1.518304          10    150103           fstat
 10.51    1.023681          20     50242       174 open
 10.12    0.986350          10    100003           lseek
  7.69    0.749387          15     50047           munmap
  6.85    0.667576          13     50071           close
  5.90    0.574888          11     50073           mmap

real    5m5.237s
user    0m7.278s
sys     0m30.736s

在打开-
T的情况下对strace输出进行了一些解析，并计算了每个文件的前8192个字节读取的时间，很明显，这是时间的去向，以下是文件的50000次首次读取所花费的总时间，然后是每次读取的平均时间。

300.247128000002 (0.00600446220302379)   - Python
11.6845620000003 (0.000233681892724297)  - Perl

不确定是否有帮助！

更新2
更新了Python中的代码以使用os.open和os.read，并且只读取前4096个字节（这对我来说是有用的，因为我想要的信息位于文件的顶部），还消除了其中的所有其他调用strace：

18346 open("1/1000.xml", O_RDONLY)      = 3 <0.000026>
18346 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 <0.007206>
18346 close(3)                          = 0 <0.000024>

$ time strace -f -c python readFiles.py 1
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 55.39    2.388932          48     50104           read
 22.86    0.986096          20     50242       174 open
 20.72    0.893579          18     50071           close

real    4m48.751s
user    0m3.078s
sys     0m12.360s

Total Time (avg read call)
282.28626 (0.00564290374812595)

还是没有更好的…下一步，我将在Azure上创建一个VM，然后在那里尝试另一个示例！

更新3-对此致歉！！

在3种设置上使用您的（@JFSebastian）脚本，可以得出一些有趣的结果，为简洁起见，在开始时删除了输出，还删除了所有从缓存运行得非常快的测试，如下所示：

0.23user 0.26system 0:00.50elapsed 99%CPU (0avgtext+0avgdata 9140maxresident)k
0inputs+0outputs (0major+2479minor)pagefaults 0swaps

Azure A2标准VM（2核3.5GB RAM磁盘未知，但速度较慢）

$ uname -a
Linux servername 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
$ perl -v
This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi
(with 41 registered patches, see perl -V for more detail)

+ /usr/bin/time perl slurp.pl 1
1.81user 2.95system 3:11.28elapsed 2%CPU (0avgtext+0avgdata 9144maxresident)k
1233840inputs+0outputs (20major+2461minor)pagefaults 0swaps
+ clearcache
+ sync
+ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python slurp.py 1
1.56user 3.76system 3:06.05elapsed 2%CPU (0avgtext+0avgdata 8024maxresident)k
1232232inputs+0outputs (14major+52273minor)pagefaults 0swaps
+ /usr/bin/time perl slurp.pl 2
1.90user 3.11system 6:02.17elapsed 1%CPU (0avgtext+0avgdata 9144maxresident)k
1233776inputs+0outputs (16major+2465minor)pagefaults 0swaps

两者的第一口结果相当，不确定第二次Perl口期间发生了什么？

我的VMWare Linux VM（2核8GB RAM磁盘RAID1 SSD）

$ uname -a
Linux servername 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
$ perl -v
This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi
(with 41 registered patches, see perl -V for more detail)

+ /usr/bin/time perl slurp.pl 1
1.66user 2.55system 0:13.28elapsed 31%CPU (0avgtext+0avgdata 9136maxresident)k
1233152inputs+0outputs (20major+2460minor)pagefaults 0swaps
+ clearcache
+ sync
+ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python slurp.py 1
2.10user 4.67system 4:45.65elapsed 2%CPU (0avgtext+0avgdata 8012maxresident)k
1232056inputs+0outputs (14major+52269minor)pagefaults 0swaps
+ /usr/bin/time perl slurp.pl 2
2.13user 4.11system 5:01.40elapsed 2%CPU (0avgtext+0avgdata 9140maxresident)k
1233264inputs+0outputs (16major+2463minor)pagefaults 0swaps

这次，像以前一样，Perl在第一次吞食时会更快，尽管之前没有看到过这种行为，但不确定在第二次Perl吞食时会发生什么。再次运行measure.sh，结果完全相同，请花几秒钟的时间。然后，我做了任何普通人都会做的事情，并更新了内核以使其与Azure机器3.13.0-35-generic匹配，并再次运行measure.sh，对结果没有任何影响。

出于好奇，我随后在measure.sh中交换了1和2参数，发生了一些奇怪的事情。Perl变慢了，Python加速了！

+ /usr/bin/time perl slurp.pl 2
1.78user 3.46system 4:43.90elapsed 1%CPU (0avgtext+0avgdata 9140maxresident)k
1234952inputs+0outputs (21major+2458minor)pagefaults 0swaps
+ clearcache
+ sync
+ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python slurp.py 2
1.19user 3.09system 0:10.67elapsed 40%CPU (0avgtext+0avgdata 8012maxresident)k
1233632inputs+0outputs (14major+52269minor)pagefaults 0swaps
+ /usr/bin/time perl slurp.pl 1
1.36user 2.32system 0:13.40elapsed 27%CPU (0avgtext+0avgdata 9136maxresident)k
1232032inputs+0outputs (17major+2465minor)pagefaults 0swaps

这让我更加困惑：-(

物理服务器（32核132 GB RAM磁盘RAID10 SAS）

$ uname -a
Linux servername 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ python
Python 2.7.3 (default, Aug  1 2012, 05:14:39)
[GCC 4.6.3] on linux2
$ perl -v
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi
(with 55 registered patches, see perl -V for more detail)

+ /usr/bin/time perl slurp.pl 1
2.22user 2.60system 0:15.78elapsed 30%CPU (0avgtext+0avgdata 43728maxresident)k
1233264inputs+0outputs (15major+2984minor)pagefaults 0swaps
+ clearcache
+ sync
+ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python slurp.py 1
2.51user 4.79system 1:58.53elapsed 6%CPU (0avgtext+0avgdata 34256maxresident)k
1234752inputs+0outputs (16major+52385minor)pagefaults 0swaps
+ /usr/bin/time perl slurp.pl 2
2.17user 2.95system 0:06.96elapsed 73%CPU (0avgtext+0avgdata 43744maxresident)k
1232008inputs+0outputs (14major+2987minor)pagefaults 0swaps

在这里，Perl似乎每次都赢了。

莫名其妙

考虑到我本地VM上的奇怪情况，当我交换目录时，这是我最能控制的机器，我将尝试在运行python vs
perl的所有可能选项上使用1或2作为数据目录，并尝试使用二进制方法。尝试多次运行它们以保持一致性，但是要花一些时间，我会有点疯狂，因此可能需要先休息一下！我想要的只是一致性:-(

更新4-一致性

（下面在ubuntu-14.04.1服务器VM上运行，内核是3.13.0-35通用＃62-Ubuntu）

我想我已经找到了一些一致性，可以在数据目录1/2上针对Python / Perl进行各种测试，我发现了以下几点：

  • Python在创建的文件（即由dd创建的）上总是很慢
  • Python在复制的文件上总是很快速（即由cp -r创建）
  • Perl在创建的文件（例如，由dd创建）上总是很快速
  • Perl在复制的文件上总是很慢（即由cp -r创建）

因此，我研究了操作系统级别的复制，似乎在Ubuntu上，“ cp”的行为与Python相同，即原始文件运行缓慢，复制文件运行很快。

这是我运行的结果，我在具有单个SATA HD和RAID10系统的计算机上做了几次，结果是：

$ mkdir 1
$ cd 1
$ for i in {1..50000}; do dd if=/dev/urandom of=$i.xml bs=1K count=10; done
$ cd ..
$ cp -r 1 2
$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy2c cp -r 2 2copy
    real    0m28.624s
    user    0m1.429s
    sys     0m27.558s
$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy1c cp -r 1 1copy
    real    5m21.166s
    user    0m1.348s
    sys     0m30.717s

跟踪结果显示了花费的时间

$ head trace.copy1c trace.copy2c
==> trace.copy1c <==
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 60.09    2.541250          25    100008           read
 12.22    0.516799          10     50000           write
  9.62    0.406904           4    100009           open
  5.59    0.236274           2    100013           close
  4.80    0.203114           4     50004         1 lstat
  4.71    0.199211           2    100009           fstat
  2.19    0.092662           2     50000           fadvise64
  0.72    0.030418         608        50           getdents
==> trace.copy2c <==
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 47.86    0.802376           8    100008           read
 13.55    0.227108           5     50000           write
 13.02    0.218312           2    100009           open
  7.36    0.123364           1    100013           close
  6.83    0.114589           1    100009           fstat
  6.31    0.105742           2     50004         1 lstat
  3.38    0.056634           1     50000           fadvise64
  1.62    0.027191         544        50           getdents

因此，似乎复制副本比复制原始文件要快得多，我目前的猜测是，复制后的文件在磁盘上的对齐方式要比原始创建时的对齐方式更好，从而使文件的读取效率更高？

有趣的是，“ rsyn”和“ cp”似乎以相反的方式快速运行，就像Perl和Python！

$ rm -rf 1copy 2copy; sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Rsync 1"; /usr/bin/time rsync -a 1 1copy; sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Rsync 2"; /usr/bin/time rsync -a 2 2copy
Rsync 1
    3.62user 3.76system 0:13.00elapsed 56%CPU (0avgtext+0avgdata 5072maxresident)k
    1230600inputs+1200000outputs (13major+2684minor)pagefaults 0swaps
Rsync 2
    4.87user 6.52system 5:06.24elapsed 3%CPU (0avgtext+0avgdata 5076maxresident)k
    1231832inputs+1200000outputs (13major+2689minor)pagefaults 0swaps

$ rm -rf 1copy 2copy; sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Copy 1"; /usr/bin/time cp -r 1 1copy; sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Copy 2"; /usr/bin/time cp -r 2 2copy
Copy 1
    0.48user 6.42system 5:05.30elapsed 2%CPU (0avgtext+0avgdata 1212maxresident)k
    1229432inputs+1200000outputs (6major+415minor)pagefaults 0swaps
Copy 2
    0.33user 4.17system 0:11.13elapsed 40%CPU (0avgtext+0avgdata 1212maxresident)k
    1230416inputs+1200000outputs (6major+414minor)pagefaults 0swaps

问题答案：

我将只关注您的示例之一，因为其余的事情应该是类比的：

我认为，在这种情况下可能重要的是预读（或与此有关的另一种技术）功能：

让我们考虑这样的例子：

我已经按照dd命令在“ 1”目录（名称1.xml到1000.xml）中创建了1000个xml文件，然后将原始目录1复制到目录2

$ mkdir 1
$ cd 1
$ for i in {1..1000}; do dd if=/dev/urandom of=$i.xml bs=1K count=10; done
$ cd ..
$ cp -r 1 2
$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy2c cp -r 2 2copy
$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy1c cp -r 1 1copy

在下一步中，我调试了cp命令（通过strace）以找出按什么顺序复制数据：

因此cp按以下顺序执行（仅前4个文件，因为我看到从原始目录中进行第二次读取比从复制目录中进行第二次读取更耗时）

100.xml 150.xml 58.xml 64.xml … *在我的示例中

现在，看看这些文件使用的文件系统块（debugfs输出-ext3 fs）：

原始目录：

BLOCKS:
(0-9):63038-63047 100.xml
(0-9):64091-64100 150.xml
(0-9):57926-57935 58.xml
(0-9):60959-60968 64.xml
....


Copied directory:
BLOCKS:
(0-9):65791-65800 100.xml
(0-9):65801-65810 150.xml
(0-9):65811-65820 58.xml
(0-9):65821-65830 64.xml

....

如您所见，在“复制的目录”中，该块相邻，因此这意味着在读取第一个文件100.xml期间，“预读”技术（控制器或系统设置）可以提高性能。

dd以1.xml到1000.xml的顺序创建文件，但是cp命令以另一顺序（100.xml，150.xml，58.xml，64.xml）复制它。因此，当您执行时：

cp -r 1 1copy

要将这个目录复制到另一个目录，复制的文件块是不相邻的，因此读取此类文件会花费更多时间。

当您复制由cp命令复制的dir（因此文件不是由dd命令创建的）时，文件是相邻的，因此创建：

cp -r 2 2copy

副本的副本速度更快。

摘要：因此，要测试python /
perl的性能，您应该使用相同的目录（或cp命令复制的两个目录），还可以使用选项O_DIRECT绕过所有内核缓冲区进行读取，并直接从磁盘读取数据。

请记住，在不同类型的内核，系统，磁盘控制器，系统设置，fs等上，结果可能会有所不同。

补充：

 [debugfs] 
[root@dhcppc3 test]# debugfs /dev/sda1 
debugfs 1.39 (29-May-2006)
debugfs:  cd test
debugfs:  stat test.xml
Inode: 24102   Type: regular    Mode:  0644   Flags: 0x0   Generation: 3385884179
User:     0   Group:     0   Size: 4
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 2
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x543274bf -- Mon Oct  6 06:53:51 2014
atime: 0x543274be -- Mon Oct  6 06:53:50 2014
mtime: 0x543274bf -- Mon Oct  6 06:53:51 2014
BLOCKS:
(0):29935
TOTAL: 1

debugfs:


 类似资料：
  • elasticsearch - ES查询速度慢的问题？

    现在有三台ES服务器，索引里大概有7000条数据，每条数据是内容放到txt中大概300kb以上，按某个查询条件查询的结果数量是4000多条数据。当size设置成9999的时候，需要查询30秒以上，这是为什么呢，有没有优化方案。

  • mq慢速持久消息读取

    我正试图追踪一个客户不能以他们应该的速度读取消息的问题。持久消息被写入队列。有时，GET速率比PUT速率慢，我们会看到消息备份。

  • 使用GCP Dataflow从GCS读取数据的速度非常慢&Apache Beam Python SDK

    首先让我先说明一下，我刚刚开始了解如何使用Beam的Python SDK和GCP Dataflow！ 问题：我的管道对于几乎所有的用例都非常有效。没有我可以抱怨的错误。我只是对一些可能的瓶颈或我可以做的优化有一些问题。我注意到，当处理大小为50MB的gzipped文件时，我的管道执行时间几乎超过3个小时。不完全确定是否有任何方法来加快这一部分。下面是在作业最终成功完成之前我看到的一堆日志警告的截图

  • Python urllib2.urlopen（）速度很慢，需要一种更好的方式来读取多个URL

    问题内容： 顾名思义，我正在使用python编写的网站上，它对urllib2模块进行了多次调用以读取网站。然后，我用BeautifulSoup解析它们。 由于我必须阅读5-10个站点，因此页面需要一段时间才能加载。 我只是想知道是否可以同时阅读所有站点？还是任何使它更快的技巧，例如我应该在每次读取后关闭urllib2.urlopen还是将其保持打开状态？ 补充 ：另外，如果我只是改用php，从其他

  • Python-为什么DataFrames的串联速度变慢？

    问题内容： 我有一个处理DataFrame的函数，主要用于将数据处理到存储桶中，使用会在特定列中创建功能的二进制矩阵。 为了避免立即使用此函数处理所有数据（该数据将耗尽内存并导致iPython崩溃），我使用以下方法将大型DataFrame分为多个块： 会自动创建一个基于内容的新栏目和这些都有可能为每个不同df在df_list。 加工后，我串接DataFrames回到一起使用： 第一块的处理时间是完

  • 在Java7下，jmap的运行速度较慢，JVM的运行速度较慢

    我们已经使用jmap在Java 6下运行的大型多服务器应用程序上测量堆大小大约2年了。我们每分钟测量一次。每次测量所用的时间（经过的时间）不到1秒。 我们现在正在Java 7下测试同一个应用程序。现在突然之间，jmap通常需要10秒、20秒，有时甚至更长时间，而且它似乎慢了下来（甚至可能停止！）在那段时间里，JVM。 我们在jmap输出中看到的唯一区别（Java6和Java7之间）是关于有多少字符

  • PHP与MySQL的速度很慢

    问题内容： （重要）编辑3： 单独运行testajax2.php而 _不是_Ajax。持续时间大致相同，为1.02-1.03秒。所以我想这意味着问题出在PHP- MySQL或XAMPP中？ 当我通过phpMyAdmin查询运行它时，结果如下：显示第0-29行（总计约50行。查询用时 0.0015秒 ）。看来问题根本不在于Ajax，而可能在于PHP。我怎样才能解决这个问题？（我也刚刚编辑了问题标题。

  • python读取文本绘制动态速度曲线

    本文向大家介绍python读取文本绘制动态速度曲线，包括了python读取文本绘制动态速度曲线的使用技巧和注意事项，需要的朋友参考一下 本文实例为大家分享了python读取文本绘制动态速度曲线的具体代码，供大家参考，具体内容如下 由于需要分析机械加工过程中各个轴的速度，于是用软件导出了数据，写了这个python脚本来显示速度曲线。 效果图如下： 源代码： 读取的文本格式如下： 以上就是本文的全部内

相关阅读

unity3d 读取加速度传感器（精度）Python库安装速度过慢解决方案python 不同方式读取文件速度不同的实例Ruby on Rails中jquery_ujs组件拖慢速度的问题解决Google BigQuery查询速度很慢

相关文章

Jsoup 读取URL获取HTMLFirebase读取数据Cassandra读取数据PDFBox读取文档OpenCV读取图像

相关问答

Spark csv读取速度非常慢，尽管我增加了节点数带dask sel的xarray速度很慢java慢速：熵相关问题JDBC模板工作速度慢mysql响应查询速度慢

相关工具

加速度传感器的使用深度学习500问读取txt并实现翻页效果极速连连看无尽的进度条

相关文档

Python 快速教程Python 深度学习Python 深度学习Speed sensor 速度传感器 使用手册Keras 基于 Python 的深度学习库
快捷导航： 新手教程 算法原理 架构设计 Java进阶 数据库进阶 大厂专栏 面试经验 编程笔记 编程问答 所有专题 文档资料 工具软件 电子书籍 小牛导航
在线工具： 房贷计算器 个税计算器 Linux命令查询 Json格式化 正则表达式 颜色转换 AES加解密 SHA1加密 MD5加密 毒鸡汤 字数统计 随机密码生成 进制转换 Base64编解码 励志句子
Copyright © 2019-2024 小牛知识库@xnip.cn. All Rights Reserved.