currently i try to optimize our system so that the landing-page if it
does not contain forms and when no user is logged in could be cached
with APCu which works fine so far
there is still a early session_start(); and while delay that would be
probably possible like it's happening currently with database connection
on-demand
but there are some important things written in $_SESSION which i can't
delay and the sample below shows that they would get lost in case it's
not a cache hit
<?php declare(strict_types=1);
if(!empty($_SESSION['test']))
{
echo $_SESSION['test'];
}
$_SESSION['test'] = 'test';
session_start();
if that could work in the way that session_start() keeps the current
state of $_SESSION if not empty it would be possible to put the
APCU-Read and if exit($apcu_content); before session_start() which would
gain another 30% performance
if that could work in the way that
session_start()keeps the current
state of $_SESSION if not empty it would be possible to put the
APCU-Read and if exit($apcu_content); beforesession_start()which
would
gain another 30% performance
I think that behaviour would confuse more people than it would help. If anything, it should be an error to access $_ SESSION if no session is currently open - if there is no session, the array has no meaning. (Arguably, all the other superglobals should be read only for the same reason, but that would be a huge break now.)
If I understand you right, the scenario you describe is "I don't want to start a session yet, but if and when I do, I want to put this data into it". It feels like that could be adequately handled in userland with a wrapper object (or global var and functions if you prefer), which reads to and from $_SESSION when a session is open, but a a holding array when it's not yet.
Regards,
--
Rowan Collins
[IMSoP]
Am 28.07.2017 um 14:48 schrieb Rowan Collins:
if that could work in the way that
session_start()keeps the current
state of $_SESSION if not empty it would be possible to put the
APCU-Read and if exit($apcu_content); beforesession_start()which
would
gain another 30% performanceI think that behaviour would confuse more people than it would help. If anything, it should be an error to access $_ SESSION if no session is currently open - if there is no session, the array has no meaning. (Arguably, all the other superglobals should be read only for the same reason, but that would be a huge break now.)
make them readonly would break my whole codebase including autotests and
code-coverage tools because it is legit to as example fill
$_SERVER['SERVER_NAME'] with specific informations to define a straight
behavior when running in cli-test-mode instead wrap every basic thing in
function calls - at the curretn state a core-cms cache-hit has a total
of 32 funtion calls including PHP internal ones
hence that 3 bugreport are becoming a MAJOR PROBLEM because the system
itself is so fast that under load after a short time you get problems
with dattabase connections and with persistent connections because of
the third one after the load is gone any strict-typed application jsut
breaks horrible
https://bugs.php.net/bug.php?id=74971
https://bugs.php.net/bug.php?id=74970
https://bugs.php.net/bug.php?id=74967
If I understand you right, the scenario you describe is "I don't want to start a session yet, but if and when I do, I want to put this data into it". It feels like that could be adequately handled in userland with a wrapper object (or global var and functions if you prefer), which reads to and from $_SESSION when a session is open, but a a holding array when it's not yet.
that don't work because at this point you don't know in userland if you
started a completly new session which should be initialized with values
for follow-up requests or use the existing values from a previous
request - at least not without writing ugly code
session_start() knows that and would only need a flag if it is desired
to bail out as you said above or as for this case init the session with
specific values
(Arguably, all the other superglobals should be read only for the same
reason, but that would be a huge break now.)make them readonly would break my whole codebase
Yes, I only meant that as an absolutely hypothetical "if I had a time machine and could design it a different way...", I realise it would break everything to change it now.
If I understand you right, the scenario you describe is "I don't want
to start a session yet, but if and when I do, I want to put this data
into it". It feels like that could be adequately handled in userland
with a wrapper object (or global var and functions if you prefer),
which reads to and from $_SESSION when a session is open, but a a
holding array when it's not yet.that don't work because at this point you don't know in userland if you
started a completly new session which should be initialized with values
for follow-up requests or use the existing values from a previous
request - at least not without writing ugly code
Do you mean like this?
session_start();
if ( ! $_SESSION['initialised'] ) {
$_SESSION['initialised'] = true;
foreach ( $this->session_init_vars as $var => $val ) {
$_SESSION[ $var ] = $val;
}
}
That should work as long as you don't run session_start() outside that function, and centralising that is already necessary to avoid "already started" errors.
Regards,
--
Rowan Collins
[IMSoP]
(Arguably, all the other superglobals should be read only for the same
reason, but that would be a huge break now.)make them readonly would break my whole codebase
Yes, I only meant that as an absolutely hypothetical "if I had a time machine and could design it a different way...", I realise it would break everything to change it now.
ftr; I'd vote in favor of several BC breaking things to do with
autoglobals, among them:
- Make them objects (though ArrayAccess based for less hostile BC breakage)
- Make most of them read-only (offsetGet(), but no offsetSet)
- Make $_SESSION[...] access produce an error or auto-start the session
I've seen too many codebases abuse GPCER vars as a generic storage
location because "globals are bad, but this is good because it doesn't
include the word global". As a performance issue, the runtime has to
assume autoglobals are inherently volatile and could change on a whim
at any moment (much like $http_response_headers). Restricting their
mutability would be a win. The request globals could probably also be
optimized fairly significantly.
If anyone agrees, I'm willing to RFC it. If not, I'll continue living
with it. :D
-Sara
Hi,
ftr; I'd vote in favor of several BC breaking things to do with
autoglobals, among them:
- Make them objects (though ArrayAccess based for less hostile BC breakage)
- Make most of them read-only (offsetGet(), but no offsetSet)
- Make $_SESSION[...] access produce an error or auto-start the session
I've seen too many codebases abuse GPCER vars as a generic storage
location because "globals are bad, but this is good because it doesn't
include the word global". As a performance issue, the runtime has to
assume autoglobals are inherently volatile and could change on a whim
at any moment (much like $http_response_headers). Restricting their
mutability would be a win. The request globals could probably also be
optimized fairly significantly.If anyone agrees, I'm willing to RFC it. If not, I'll continue living
with it. :D
Yes, please!
Am 28.07.2017 um 16:48 schrieb Andrey Andreev:
Hi,
ftr; I'd vote in favor of several BC breaking things to do with
autoglobals, among them:
- Make them objects (though ArrayAccess based for less hostile BC breakage)
- Make most of them read-only (offsetGet(), but no offsetSet)
- Make $_SESSION[...] access produce an error or auto-start the session
I've seen too many codebases abuse GPCER vars as a generic storage
location because "globals are bad, but this is good because it doesn't
include the word global". As a performance issue, the runtime has to
assume autoglobals are inherently volatile and could change on a whim
at any moment (much like $http_response_headers). Restricting their
mutability would be a win. The request globals could probably also be
optimized fairly significantly.If anyone agrees, I'm willing to RFC it. If not, I'll continue living
with it. :DYes, please!
raise a warning when write to $_SESSION without a session_start()
make a implicit autostart - for sure not this would only produce
hidden errors or later warnings when you rely on session params and
introduce more problems that it solves because clients don't like the
same cookies ith different params
make POST/GET/SERVER readonly - only when you refactor a 250000 line
code base as well as deplyed code which relies on the framework did the
right thing with them previously :-)