Message315427
| Author | gitinit.py@gmail.com |
|---|---|
| Recipients | christian.heimes, gitinit.py@gmail.com, paul.moore, python-dev, serhiy.storchaka, steve.dower, tim.golden, vstinner, zach.ware |
| Date | 2018-04-17.23:39:13 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1524008353.89.0.682650639539.issue28126@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Py_MEMCPY() has a special case for small blocks on Windows to work around an ancient performance issue in MSVC. Can we safely assume that recent MSVC properly optimize memcpy()? See #28055 /* Py_MEMCPY can be used instead of memcpy in cases where the copied blocks * are often very short. While most platforms have highly optimized code for * large transfers, the setup costs for memcpy are often quite high. MEMCPY * solves this by doing short copies "in line". */ #if defined(_MSC_VER) #define Py_MEMCPY(target, source, length) do { \ size_t i_, n_ = (length); \ char *t_ = (void*) (target); \ const char *s_ = (void*) (source); \ if (n_ >= 16) \ memcpy(t_, s_, n_); \ else \ for (i_ = 0; i_ < n_; i_++) \ t_[i_] = s_[i_]; \ } while (0) #else #define Py_MEMCPY memcpy #endif |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2018-04-17 23:39:13 | gitinit.py@gmail.com | set | recipients: + gitinit.py@gmail.com, paul.moore, vstinner, christian.heimes, tim.golden, python-dev, zach.ware, serhiy.storchaka, steve.dower |
| 2018-04-17 23:39:13 | gitinit.py@gmail.com | set | messageid: <1524008353.89.0.682650639539.issue28126@psf.upfronthosting.co.za> |
| 2018-04-17 23:39:13 | gitinit.py@gmail.com | link | issue28126 messages |
| 2018-04-17 23:39:13 | gitinit.py@gmail.com | create | |